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Chapter  1 


Introduction 


In  this  book  we  shall  introduce  four  of  the  main  approaches  to  program  anal¬ 
ysis:  Data  Flow  Analysis,  Control  Flow  Analysis,  Abstract  Interpretation, 
and  Type  and  Effect  Systems.  Each  of  Chapters  2  to  5  deals  with  one  of 
these  approaches  to  some  length  and  generally  treats  the  more  advanced  ma¬ 
terial  in  later  sections.  Throughout  the  book  we  aim  at  stressing  the  many 
similarities  between  what  may  at  a  first  glance  appear  to  be  very  unrelated 
approaches.  To  help  getting  this  idea  across,  and  to  serve  as  a  gentle  intro¬ 
duction,  this  chapter  treats  all  of-the  approaches  at  the  level  of  examples. 
The  technical  details  are  worked'out  but  it  may  be  difficult  to  apply  the 
techniques  to  related  examples  until  some  of  the  material  of  later  chapters 
have  been  studied. 


1.1  The  Nature  of  Program  Analysis 

Program  analysis  offers  static  compile-time  techniques  for  predicting  safe 
and  computable  approximations  to  the  set  of  values  or  behaviours  arising 
dynamically  at  run-time  when  executing  a  program  on  a  computer.  A  main 
application  is  to  allow  compilers  to  generate  code  avoiding  redundant  com¬ 
putations,  e.g.  by  reusing  available  results  or  by  moving  loop  invariant  com¬ 
putations  out  of  loops,  or  avoiding  superfluous  computations,  e.g.  of  results 
known  to  be  not  needed  or  of  results  known  already  at  compile-time.  Among 
the  more  recent  applications  is  the  validation  of  software  (possibly  purchased 
from  sub-contractors)  to  reduce  the  likelihood  of  malicious  or  unintended  be¬ 
haviour.  Common  for  these  applications  is  the  need  to  combine  information 
from  different  parts  of  the  program. 

A  main  aim  of  this  book  is  to  give  an  overview  of  a  number  of  approaches  to 
program  analysis,  all  of  which  have  a  quite  extensive  literature,  and  to  show 
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true  answer 

{dl,*‘*,dn}  {^n+1  j  *  *  *  >  djv} 


{dl,  '  *  '  >  dn,  *  ’  *  >  ^n+m} 
safe  answer 


Figure  1.1:  The  nature  of  approximation:  erring  on  the  safe  side. 


that  there  is  a  large  amount  of  commonality  among  the  approaches.  This 
should  help  in  cultivating  the  ability  to  choose  the  right  approach  for  the 
right  task  and  in  exploiting  insights  developed  in  one  approach  to  enhance 
the  power  of  other  approaches. 

One  common  theme  behind  all  approaches  to  program  analysis  is  that  in 
order  to  remain  computable  one  can  only  provide  approximate  answers.  As 
an  example  consider  a  simple  language  of  statements  and  the  program 

read(x);  (if  x>0  then  y:=l  else  (y:=2;S));  z:=y 

where  S  is  some  statement  that  does  not  contain  an  assignment  to  y.  Intu¬ 
itively,  the  values  of  y  that  can  reach  z:=y  will  be  1  or  2. 

Now  suppose  an  analysis  claims  that  the  only  value  for  y  that  can  reach  z :  =y 
is  in  fact  1.  While  this  seems  intuitively  wrong,  it  is  in  fact  correct  in  the 
case  where  S  is  known  never  to  terminate  for  x  <  0  and  y  =  2.  But  since 
it  is  undecidable  whether  or  not  S  terminates,  we  normally  do  not  expect 
our  analysis  to  attempt  to  detect  this  situation.  So  in  general,  we  expect  the 
program  analysis  to  produce  a  possibly  larger  set  of  possibilities  than  what 
will  ever  happen  during  execution  of  the  program.  This  means  that  we  shall 
also  accept  a  program  analysis  claiming  that  the  values  of  y  reaching  z :  =y 
are  among  1,  2  or  27,  although  we  will  clearly  prefer  the  analysis  that  gives 
the  more  precise  answer  that  the  values  are  among  1  or  2.  This  notion  of 
safe  approximation  is  illustrated  in  Figure  1.1.  Clearly  the  challenge  is  not  to 
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produce  the  safe  “{di ,  •  •  • ,  djv}”  too  often  as  the  analysis  will  then  be  utterly 
useless.  Note,  that  although  the  analysis  does  not  give  precise  information  it 
may  still  give  useful  information:  knowing  that  the  value  of  y  is  one  of  1,  2 
and  27  just  before  the  assignment  z :  =y  still  tells  us  that  z  will  be  positive, 
and  that  z  will  fit  within  1  byte  of  storage  etc.  To  avoid  confusion  it  may 
help  to  be  precise  in  the  use  of  terminology:  it  is  better  to  say  “the  values 
of  y  possible  at  z :  =y  are  among  1  and  2”  than  the  slightly  shorter  and  more 
frequently  used  “the  values  of  y  possible  at  z :  =y  are  1  and  2” . 

Another  common  theme,  to  be  stressed  throughout  this  book,  is  that  all 
program  analyses  should  be  semantics  based:  this  means  that  the  information 
obtained  from  the  analysis  can  be  proved  to  be  safe  (or  correct)  with  respect 
to  a  semantics  of  the  programming  language.  It  is  a  sad  fact  that  new  program 
analyses  often  contain  subtle  bugs,  and  a  formal  justification  of  the  program 
analysis  will  help  finding  these  bugs  sooner  rather  than  later.  However,  we 
should  stress  that  we  do  not  suggest  that  program  analyses  be  semantics 
directed:  this  would  mean  that  the  structure  of  the  program  analysis  should 
reflect  the  structure  of  the  semantics  and  this  will  be  the  case  only  for  a  few 
approaches  which  are  not  covered  in  this  book. 


1.2  Setting  the  Scene 

Syntax  of  the  While  language.  We  shall  consider  a  simple  im¬ 
perative  language  called  While.  A  program  in  While  is  just  a  statement 
which  may  be,  and  normally  will  be,  a  sequence  of  statements.  In  the  interest 
of  simplicity,  we  will  associate  data  flow  information  with  single  assignment 
statements,  the  tests  that  appear  in  conditionals  and  loops,  and  skip  state¬ 
ments.  We  will  require  a  method  to  identify  these.  The  most  convenient 
way  of  doing  this  is  to  work  with  a  labelled  program  -  as  indicated  in  the 
syntax  below.  We  will  often  refer  to  the  labelled  items  (assignments,  tests 
and  skip  statements)  as  elementary  blocks.  In  this  chapter  we  will  assume 
that  distinct  elementary  blocks  are  initially  assigned  distinct  labels;  we  could 
drop  this  requirement,  in  which  case  some  of  the  examples  would  need  to  be 
slightly  reformulated  and  the  resultant  analyses  would  be  less  accurate. 

We  use  the  following  syntactic  categories: 

a  £  AExp  arithmetic  expressions 
b  £  BExp  boolean  expressions 
S  €  Stmt  statements 

We  assume  some  countable  set  of  variables  is  given;  numerals  and  labels  will 
not  be  further  defined  and  neither  will  the  operators: 

x,  y  £  Var  variables 
n  £  Num  numerals 
l  £  Lab  labels 
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RDentry(^) 

RDexit(t) 

1 

(*,?),  (y,?),(z,?) 

(x,  ?),(y,  l),(z,  ?) 

2 

(x,  ?)>  (y,  1),  (z,  ?) 

(x,?),(y,i)»(z,2) 

3 

(x,?),(y,l),(y,5),(z,2),(z,4) 

(x.?).(y.l),(y,5),(z,2),(z,4) 

4 

(x,?)>(y,i),(y,5),(z,2),(z,4) 

(x1?)»(y,i).(y»5)>(z,4) 

5 

(x-?).(y,  i),(y,5),(z,4) 

(x,?),(y>5),(z,4) 

6 

(x,?),(y,l),(y,5),(z,2),(z,4) 

(x,  ?),  (y,  6),  (z,  2),  (z,  4) 

Table  1.1:  Reaching  Definitions  information  for  the  factorial  program. 

opa  €  Opa  arithmetic  operators 
opb  €  Opt  boolean  operators 
opr  €  Opr  relational  operators 

The  syntax  of  the  language  is  given  by  the  following  abstract  syntax-, 
a  ::=  x  \  n  \  ai  opa  a 2 

b  ::=  true  |  false  |  not  b  |  61  opb  62  |  a  1  opr  02 

S  ::=  [r  :=  a]*  |  [skip]*  |  Si;S2  | 

if  [6]*  then  S\  else  S%  |  while  [6]*  do  S 

One  way  to  think  of  the  abstract  syntax  is  as  specifying  the  parse  trees  of 
the  language;  it  will  then  be  the  purpose  of  the  concrete  syntax  to  provide 
sufficient  information  to  enable  urifque  parse  trees  to  be  constructed.  In  this 
book  shall  not  be  concerned  with  concrete  syntax:  whenever  we  talk  about 
some  syntactic  entity  we  will  always  be  talking  about  the  abstract  syntax  so 
there  will  be  no  ambiguity  with  respect  to  the  form  of  the  entity.  We  shall 
use  a  textual  representation  of  the  abstract  syntax  and  to  disambiguate  it 
we  shall  use  parentheses.  For  statements  one  often  writes  begin  •  •  •  end  or 
{•  •  •}  for  this  but  we  shall  feel  free  to  use  (•••)•  Similarly,  we  use  brackets 
(•  •  •)  to  resolve  ambiguities  in  other  syntactic  categories.  To  cut  down  on  the 
number  of  brackets  needed  we  shall  use  the  familiar  relative  precedences  of 
arithmetic,  boolean  and  relational  operators. 

Example  1.1  An  example  of  a  program  written  in  this  language  is  the 
following  which  computes  the  factorial  of  the  number  stored  in  x  and  leaves 
the  result  in  z: 

[y:=x]*;  [z:=l]2;  while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y :=0]6  ■ 

Reaching  Definitions  Analysis.  The  use  of  distinct  labels  allows 
us  to  identify  the  primitive  constructs  of  a  program  without  explicitly  con¬ 
structing  a  flow  graph  (or  flow  chart).  It  also  allows  us  to  introduce  a  program 
analysis  to  be  used  throughout  the  chapter:  Reaching  Definitions  Analysis, 
or  as  it  more  properly  should  be  called,  reaching  assignments  analysis: 
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An  assignment  (called  a  definition  in  classical  literature)  of  the 
form  [z  :=  a]*  may  reach  a  certain  program  point  (typically  the 
entry  or  exit  of  an  elementary  block)  if  there  is  an  execution  of  the 
program  where  x  was  last  assigned  a  value  at  t  when  the  program 
point  is  reached. 

Consider  the  factorial  program  of  Example  1.1.  Here  [y :  =x] 1  reaches  the 
entry  to  [z:=l]2;  to  allow  a  more  succinct  presentation  we  shall  say  that 
(y,l)  reaches  the  entry  to  2.  Also  we  shall  say  that  (x,?)  reaches  the  entry  to 
2;  here  “?”  is  a  special  label  not  appearing  in  the  program  and  it  is  used  to 
record  the  possibility  of  an  uninitialised  variable  reaching  a  certain  program 
point. 

Full  information  about  reaching  definitions  for  the  factorial  program  is  then 
given  by  the  pair  RD  =  (RDentrj,,  RDexn)  of  functions  in  Table  1.1.  Careful 
inspection  of  this  table  reveals  that  the  entry  and  exit  information  agree  for 
elementary  blocks  of  the  form  [&]*  whereas  for  elementary  blocks  of  the  form 
[x  :=  a]*  they  may  differ  on  pairs  (x,£').  We  shall  come  back  to  this  when 
formulating  the  analysis  in  subsequent  sections. 

Returning  to  the  discussion  of  safe  approximation  note  that  if  we  modify 
Table  1.1  to  include  the  pair  (z,2)  in  RDentry(5)  and  RDeilf(5)  we  still  have 
safe  information  about  reaching  definitions  but  the  information  is  more  ap¬ 
proximate.  However,  if  we  remove  (z,2)  from  RDen!rv(6)  and  RDex,t(6)  then 
the  information  will  no  longer  be  safe  -  there  exists  a  run  of  the  factorial  pro¬ 
gram  where  the  set  {(x,?),(y,6),(z,4)}  does  not  correctly  describe  the  reaching 
definitions  at  the  exit  of  label  6. 


1.3  Data  Flow  Analysis 

In  Data  Flow  Analysis  it  is  customary  to  think  of  a  program  as  a  graph:  the 
nodes  are  the  elementary  blocks  and  the  edges  describe  how  control  might 
pass  from  one  elementary  block  to  another.  Figure  1.2  shows  the  flow  graph 
for  the  factorial  program  of  Example  1.1.  We  shall  first  illustrate  an  equa- 
tional  approach  to  Data  Flow  Analysis  and  then  a  constraint  based  approach. 


1.3.1  The  Equational  Approach 

The  equation  system.  An  analysis  like  Reaching  Definitions  can  be 
specified  by  extracting  a  number  of  equations  from  a  program.  There  are  two 
classes  of  equations.  One  class  of  equations  relate  exit  information  of  a  node 
to  entry  information  for  the  same  node.  For  the  factorial  program 

[y :  =x] 1 ;  [z:=l]2;  while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y:=0]6 
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Figure  1.2:  Flow  graph  for  the  factorial  program. 


we  obtain  the  following  six  equations: 

RDexit(l)  =  (RDentry (l)\{(y,  (.)  \  £  £  Lab})  U  {(y,  1)} 
RDexu(2)  =  (RDentrv(2)\{(z,  t)  \t  €  Lab})  U  {(z,  2)} 
RDexjt(3)  =  RDentrj/(3) 


RDeiit  (4)  =  (RDen^(4)\{(z,*)|£eLab})U{(z,4)} 

RDexit(5)  =  (RDeTury(5)\{(y,  £)  1 1  E  Lab})  U  {(y,  5)} 
RDexit(6)  =  (RDentrj,(6)\{(y, £)  |  i  €  Lab})  U  {(y,6)} 


These  are  instances  of  the  following  schema:  for  an  assignment  [x  :=  a}1' 
we  exclude  all  pairs  (x,  £)  from  RDeriirv(£')  and  add  (x,  £')  in  order  to  obtain 
RDexit^')  -  this  reflects  that  x  is  redefined  at  l.  For  all  other  elementary 
blocks  [•  -  • ]l  we  let  RDexjt(^')  equal  RDenirv(£')  -  reflecting  that  no  variables 
are  changed. 

The  other  class  of  equations  relate  entry  information  of  a  node  to  exit  in¬ 
formation  of  nodes  from  which  there  is  an  edge  to  the  node  of  interest;  that 
is,  entry  information  is  obtained  from  all  the  exit  information  where  control 
could  have  come  from.  For  the  example  program  we  obtain  the  following 
equations: 


RDentry(2) 


RDexit(l) 
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RDentry  (3) 

RDentry(4) 

RDe„trv(5) 

RD  entry  (6) 


RDerit(2)uRDeiij(5) 

RDexi*(3) 

RD«xit(4) 

RDexit(3) 


In  general,  we  write  RDentn/(£)  =  RDexj«(^i)  U  •••  U  RDext((^„)  if  £1,  -  •  •  ,<?n 
are  all  the  labels  from  which  control  might  pass  to  t.  We  shall  consider  more 
precise  ways  of  explaining  this  in  Chapter  2.  Finally,  let  us  consider  the 
equation 


RDentry(l)  =  {(s,  ?)  |  x  is  a  variable  in  the  program} 

that  makes  it  clear  that  the  label  “?”  is  to  be  used  for  uninitialised  variables; 
so  in  our  case 

RDentry(l)  =  {(x,?),(y,?),(2,?)} 

The  least  solution.  The  above  system  of  equations  defines  the  twelve 
sets 

RDentry(l),  ,  RDex>«(6) 

in  terms  of  each  other.  Writing  r6  for  this  twelve-tuple  of  sets  we  can  regard 
the  equation  system  as  defining  a  function  F  and  demanding  that: 

R^.  =  F(R^) 

To  be  more  specific  we  can  write 

F(R3)  = 


where  e.g.: 

Gentry  (3)(-  •  • ,  RDeli,(2),  •  ■  • ,  RDein(5),  •  •  •)  =  RDeiit(2)  U  RD«a  (5) 

It  should  be  clear  that  F  operates  over  twelve-tuples  of  sets  of  pairs  of  vari¬ 
ables  and  labels;  this  can  be  written  as 

F  :  ('P(Var*  x  Lab*))12  ->  (P(Var*  x  Lab*))12 

where  it  might  be  natural  to  take  Var*  =  Var  and  Lab*  =  Lab.  However, 
it  will  simplify  the  presentation  in  this  chapter  to  let  Var*  be  a  finite  subset 
of  Var  that  contains  the  variables  occurring  in  the  program  5*  of  interest 
and  similarly  for  Lab*.  So  for  the  example  program  we  might  have  Var*  = 
{x,  y,  z}  and  Lab*  =  {1,  •  •  • ,  6}. 

It  is  immediate  that  ('P(Var*  x  Lab*))12  can  be  partially  ordered  by  setting 
R&  C  R^'  iff  Vi :  RD<  C  RD' 


fi 
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where  m3  =  (RDi,  •  •  • ,  RD12)  and  similarly  m3  =  (RD^,  •  •  • ,  RDi2).  This 
turns  ('PCVar*  x  Lab*))12  into  a  complete  lattice  (see  Appendix  A)  with 
least  element 

0  =  (0,  — ,  0) 

and  binary  least  upper  bounds  given  by: 

m3  U  Rl3'  =  (RDi  U  RDi ,  •  •  • ,  RD12  U  RD'12) 

It  is  easy  to  show  that  F  is  in  fact  a  monotone  function  (see  Appendix  A) 
meaning  that: 

Ri$  C  R6'  implies  F0)  C  F(m3') 

This  involves  calculations  like 

RDexit(2)  C  RD'eiit(2)  and  RDeiit(5)  C  RD'esit(5) 

imply 

RDexit(2)  u  RDe*it(5)  C  RD'exit(2)  U  RD'eii<(5) 
and  the  details  are  left  to  the  reader. 

Consider  the  sequence  (Fn(0))n  and  note  that  0  C  F(0).  Since  F  is  mono¬ 
tone,  a  straightforward  mathematical  induction  (see  Appendix  B)  gives  that 
Fn(0)  C  Fn+1(0)  for  all  n.  All  the  elements  of  the  sequence  will  be  in 
(■p(Var*  x  Lab*))12  and  since  this  is  a  finite  set  it  cannot  be  the  case  that 
all  elements  of  the  sequence  are  distinct  so  there  must  be  some  n  such  that: 

-x 

Fn+1(0)  =  Fn(0) 

But  since  Fn+1  (0)  =  F(Fn(0))  this  just  says  that  Fn(0)  is  a  fixed,  point  of  F 
and  hence  that  Fn(0)  is  a  solution  to  the  above  equation  system. 

In  fact  we  have  obtained  the  least  solution  to  the  equation  system.  To  see 
this  suppose  that  Rl3  is  some  other  solution,  i.e.  Ri3  =  F(Rl3).  Then  a 
straightforward  mathematical  induction  shows  that  Fn(0)  C  Rl3.  Hence 
the  solution  Fn(0)  contains  the  fewest  pairs  of  reaching  definitions  that  is 
consistent  with  the  program,  and  intuitively,  this  is  also  the  solution  we  want: 
while  we  can  add  additional  pairs  of  reaching  definitions  without  making 
the  analysis  semantically  unsound,  this  will  make  the  analysis  less  usable  as 
discussed  in  Section  1.1.  In  Exercise  1.7  we  shall  see  that  the  least  solution 
is  in  fact  the  one  displayed  in  Table  1.1. 

1.3.2  The  Constraint  Based  Approach 

The  constraint  system.  An  alternative  to  the  equational  approach 
above  is  to  use  a  constraint  based  approach.  The  idea  is  here  to  extract  a 
number  of  inclusions  (or  in-equations  or  constraints)  out  of  a  program.  We 
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shall  present  the  constraint  system  for  Reaching  Definitions  in  such  a  way 
that  the  relationship  to  the  equational  approach  becomes  apparent;  however, 
it  is  not  a  general  phenomenon  that  the  constraints  are  naturally  divided  into 
two  classes  as  was  the  case  for  the  equations. 

For  the  factorial  program 

[y :  =x] 1 ;  [z:=l]2;  while  [y>l]3  do  ([z:=z*y]4;  [y :=y-l]5);  [y :=0]6 

we  obtain  the  following  constraints  for  expressing  the  effect  of  elementary 
blocks: 


RDexit(l) 

D 

RDe„frv(l)\{(y,f)K€Lab} 

RDeitt(l) 

D 

{(y.i)} 

RDexit(2) 

D 

RDentry(2)\{(z,^)  |  l  €  Lab} 

RDex«t(2) 

D 

{(*.2)} 

RDexj*(3) 

D 

RDentry  (3) 

RDe*»t  (4) 

D 

RDentr»(4)\{(z,0  1 1  £  Lab} 

RD  exit  (4) 

D 

{(z>4)} 

RD  exit  (5) 

D 

RDe„try(5)\{(y,^)K€Lab} 

RD  exit  (5) 

D 

{(y.5)} 

RD  exit  (d) 

D 

RDentry (6)\{(y, f)  Lab} 

RDexit(6) 

D 

{(y.6)} 

By  considering  this  system  a  certahr  methodology  emerges:  for  an  assignment 
[x  :=  a]1'  we  have  one  constraint  that  excludes  all  pairs  (x,  t)  from  RDcn(ny  ((.') 
in  reaching  RDexit(f")  and  we  have  one  constraint  for  incorporating  (x,f'); 
for  all  other  elementary  blocks  [•  ■  •]*  we  just  have  one  constraint  that  allows 
everything  in  RDenfr!/(f )  to  reach  RDe*<t(£'). 

Next  consider  the  constraints  for  more  directly  expressing  how  control  may 
flow  through  the  program.  For  the  example  program  we  obtain  the  con¬ 
straints: 


RDentry(2)  D  RDex,t(l) 
RDentry(3)  2  RDexit(2) 
RDentry(3)  D  RD  exit  (5) 
RDentry(5)  D  RDexit(4) 
RDentry(6)  2  RDeijf(3) 


In  general,  we  have  a  constraint  RDentry(f)  2  RDexit(0  if  it  is  possible  for 
control  to  pass  from  i'  to  l.  Finally,  the  constraint 


RDentn,(l)D{(x,?),(y,?),(z,?)} 

records  that  we  cannot  be  sure  about  the  definition  point  of  uninitialised 
variables. 
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The  least  solution  revisited.  It  is  not  hard  to  see  that  a  solution 
to  the  equation  system  presented  previously  will  also  be  a  solution  to  the 
above  constraint  system.  To  make  this  connection  more  transparent  we  can 
rearrange  the  constraints  by  collecting  all  constraints  with  the  same  left  hand 
side.  This  means  that  for  example 

RDexit(l)  2  RDentrj,(l)\{(y,OKeLab} 

RDexit(l)  3  {(y,  1)} 


will  be  replaced  by 

RDexit(l)  D  (RDentn/(l)\{(y,  (.)  I  e  e  Lab})  U  {(y,  1)} 

and  clearly  this  has  no  consequence  for  whether  or  not  r6  is  a  solution.  In 
other  words  we  obtain  a  version  of  the  previous  equation  system  except  that 
all  equalities  have  been  replaced  by  inclusions.  Formally,  whereas  the  equa- 
tional  approach  demands  that  Rl3  =  F(Rl5),  the  constraint  based  approach 
demands  that  R^  □  F(Rl5)  for  the  same  function  F.  It  is  therefore  immedi¬ 
ate  that  a  solution  to  the  equation  system  is  also  a  solution  to  the  constraint 
system  whereas  the  converse  is  not  necessarily  the  case. 

Luckily  we  can  show  that  both  the  equation  system  and  the  constraint  system 
have  the  same  least  solution.  Recall  that  the  least  solution  to  R&  =  F(R^) 
is  constructed  as  Fn(0)  for  a  value  of  n  such  that  F”(0)  =  Fn+1(0).  If  Rl5 
is  a  solution  to  the  constraint  system,  that  is  R^  □  F(Rt^),  then  0  C  Rt3  is 
immediate  and  the  monotonicity  of  F  and  mathematical  induction  then  gives 
Fn(0)  C  Rl3.  Since  Fn(0)  is  a  solution  to  the  constraint  system  this  shows 
that  it  is  also  the  least  solution  to  the  constraint  system. 

In  summary,  we  have  thus  seen  a  very  strong  connection  between  the  equa- 
tional  approach  and  the  constraint  based  approach.  This  connection  is  not 
always  as  apparent  as  it  is  here:  one  of  the  characteristics  of  the  constraint 
based  approach  is  that  often  constraints  with  the  same  left  hand  side  are  gen¬ 
erated  at  many  different  places  in  the  program  and  therefore  it  may  require 
serious  work  to  collect  them. 


1.4  Control  Flow  Analysis 

The  purpose  of  Control  Flow  Analysis  is  to  determine  information  about 
what  “elementary  blocks”  may  lead  to  what  other  “elementary  blocks” .  This 
information  is  immediately  available  for  the  While  language  unlike  what  is 
the  case  for  more  advanced  imperative,  functional  and  object-oriented  lan¬ 
guages. 

Consider  the  following  functional  program: 
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let  f  =  fn  x  =>  x  1; 
g  =  fn  y  =>  y+2; 
h  =  fn  z  =>  z+3 
in  (f  g)  +  (f  h) 

It  defines  a  higher-order  function  f  with  formal  parameter  x  and  body  x  1; 
then  it  defines  two  functions  g  and  h  that  are  given  as  actual  parameters  to 
f  in  the  body  of  the  let-construct.  Semantically,  x  will  be  bound  to  each 
of  these  two  functions  in  turn  so  both  g  and  h  will  be  applied  to  1  and  the 
result  of  the  computation  will  be  the  value  7. 

An  application  of  f  will  transfer  control  to  the  body  of  f ,  i.e.  to  x  1,  and 
this  application  of  x  will  transfer  control  to  the  body  of  x.  The  problem  is 
that  we  cannot  immediately  point  to  the  body  of  x:  we  need  to  know  what 
parameters  f  will  be  called  with.  This  is  exactly  the  information  that  the 
Control  Flow  Analysis  gives  us: 

For  each  function  application,  which  functions  may  be  applied. 

As  is  typical  of  functional  languages,  the  labelling  scheme  used  would  seem 
to  have  a  very  different  character  than  the  one  employed  for  imperative  lan¬ 
guages  because  the  “elementary  blocks”  may  be  nested.  We  shall  therefore 
label  all  subexpressions  as  in  the  following  simple  program  that  will  be  used 
to  illustrate  the  analysis. 

Example  1.2  Consider  the  program: 

[[fn  x  =>  [x]1]2  [fn  y  =>  [y]3]4]5 

It  calls  the  identity  function  fn  x  =>  x  on  the  argument  fn  y  =>  y  and 
clearly  evaluates  to  fn  y  =>  y  itself  (omitting  all  [•  •  •]*).  ■ 

We  shall  now  be  interested  in  associating  information  with  the  labels  them¬ 
selves,  rather  than  with  the  entries  and  exits  of  the  labels  -  thereby  we  exploit 
that  there  are  no  side-effects  in  our  simple  functional  language.  The  Control 
Flow  Analysis  will  be  specified  by  a  pair  (C,  p)  of  functions  where  C(^)  is  sup¬ 
posed  to  contain  the  values  that  the  subexpression  (or  “elementary  block”) 
labelled  t  may  evaluate  to  and  p(x)  contain  the  values  that  x  can  be  bound 
to. 

The  constraint  system.  One  way  to  specify  the  Control  Flow  Anal¬ 
ysis  then  is  by  means  of  a  collection  of  constraints  and  we  shall  illustrate  this 
for  the  program  of  Example  1.2.  There  are  three  classes  of  constraints.  One 
class  of  constraints  relate  the  values  of  function  abstractions  to  their  labels: 

{fn  x  =>  [x]1}  C  C(2) 

{fn  y  =>  [y]3}  C  C(4) 


12 


INTRODUCTION 


These  constraints  state  that  a  function  abstraction  evaluates  to  a  closure 
containing  the  abstraction  itself.  So  the  general  pattern  is  that  an  occurrence 
of  [fn  x  =>  e ]e  in  the  program  gives  rise  to  a  constraint  {fn  x  =>  e}  C  C(£). 

The  second  class  of  constraints  relate  the  values  of  variables  to  their  labels: 

p(x)  C  C(l) 
p(y)  C  C(3) 

The  constraints  state  that  a  variable  always  evaluates  to  its  value.  So  for 
each  occurrence  of  [r]?  in  the  program  we  will  have  a  constraint  p(x)  C  C(^). 

The  third  class  of  constraints  concerns  function  application:  for  each  applica¬ 
tion  point  [ei  e2]^,  and  for  each  possible  function  [fn  x  =>  e]1  that  could  be 
called  at  this  point,  we  will  have:  (i)  a  constraint  expressing  that  the  formal 
parameter  of  the  function  is  bound  to  the  actual  parameter  at  the  application 
point,  and  (ii)  a  constraint  expressing  that  the  result  obtained  by  evaluating 
the  body  of  the  function  is  a  possible  result  of  the  application. 

Our  example  program  has  just  one  application  [[•  •  *]2  [•  •  -]4]5,  but  there  are 
two  candidates  for  the  function,  i.e.  C(2)  is  a  subset  of  the  set  {fn  x  =>  [x]1, 
fn  y  =>  [y]3}.  If  the  function  fn  x  =>  [x]1  is  applied  then  the  two  con¬ 
straints  are  C(4)  C  p(x)  and  C(l)  C  C(5).  We  express  this  as  conditional 
constraints: 

{fn  x  =>  [x]1}  C  C(2)  =>  C(4)  C  p(x) 

{fn  x  =>  [xj{-}  C  C(2)  =*  C(l)  C  C(5) 

Alternatively,  the  function  being  applied  could  be  fn  y  =>  [y]3  and  the  cor¬ 
responding  conditional  constraints  are: 

{fn  y  =>  [y]3}  C  C(2)  =>■  C(4)  C  p( y) 

{fn  y  =>  [y]3}  C  C(2)  =*  C(3)  C  C(5) 

The  least  solution.  As  in  Section  1.3  we  shall  be  interested  in  the 
least  solution  to  this  set  of  constraints:  the  smaller  the  sets  of  values  given 
by  C  and  p,  the  more  precise  the  analysis  is  in  predicting  which  functions  are 
applied.  In  Exercise  1.2  we  show  that  the  following  choice  of  C  and  p  gives  a 
solution  to  the  above  constraints: 

C(l)  =  {fn  y  =>  [y]3} 

C(2)  =  {fn  x  =>  [x]1} 

C(3)  =  0 

C(4)  =  {fn  y  =>  [y]3} 

C(5)  =  {fn  y  =>  [y]3} 

PM  =  {fn  y  =>  [y]3} 

p( y)  =  0 
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Among  other  things  this  tells  us  that  the  function  abstraction  f  n  y  =>  y  is 
never  applied  (since  p{ y)  =  0)  and  that  the  program  may  only  evaluate  to 
the  function  abstraction  fn  y  =>  y  (since  C(5)  =  {fn  y  =>  [y]3}). 

Note  the  similarities  between  the  constraint  based  approaches  to  Data  Flow 
Analysis  and  Control  Flow  Analysis:  in  both  cases  the  syntactic  structure  of 
the  program  gives  rise  to  a  set  of  constraints  whose  least  solution  is  desired. 
The  main  difference  is  that  the  constraints  for  the  Control  Flow  Analysis 
have  a  more  complex  structure  than  those  for  the  Data  Flow  Analysis. 


1.5  Abstract  Interpretation 

The  theory  of  Abstract  Interpretation  is  a  general  methodology  for  calculat¬ 
ing  analyses  rather  than  just  specifying  them  and  then  rely  on  a  posteriori 
validation.  To  some  extent  the  application  of  Abstract  Interpretation  is  in¬ 
dependent  of  the  specification  style  used  for  presenting  the  program  analysis 
and  so  applies  not  only  to  the  Data  Flow  Analysis  formulation  to  be  used 
here. 

Collecting  semantics.  As  a  preliminary  step  we  shall  formulate  a  so- 
called  collecting  semantics  that  records  the  set  of  traces  tr  that  can  reach  a 
given  program  point: 

tr  G  Trace  =  (Var  x  Lab)* 

Intuitively,  a  trace  will  record  where  the  variables  have  obtained  their  values 
in  the  course  of  the  computation.  So  for  the  factorial  program 

[y :  =x] 1 ;  [z:=l]2;  while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y:=0]6 

we  will  e.g.  have  the  trace 

((*,  ?),  (y,  ?),  (z,  ?),  (y,  1),  (z,  2),  (z, 4),  (y,  5),  (z,  4),  (y,  5),  (y,  6)) 

corresponding  to  a  run  of  the  program  where  the  body  of  the  while-loop  is 
executed  twice. 

The  traces  contain  sufficient  information  that  we  can  extract  a  set  of  seman¬ 
tically  reaching  definitions: 

SRD(tr)(x)  =  l  iff  the  rightmost  pair  {x,t)  in  tr  has  l  =  (! 

In  order  for  the  Reaching  Definitions  Analysis  to  be  correct  (or  safe)  we  shall 
require  that  it  captures  the  semantic  reaching  definitions,  that  is,  if  tr  is  a 
possible  trace  just  before  entering  the  elementary  block  labelled  I  then  we 
shall  demand  that 


Vx  6  Var  :  (x,  SRD (tr)(x))  G  RDenfry(£) 
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in  order  to  trust  the  information  in  RD  about  the  set  of  definitions 

that  may  reach  the  entry  to  t.  In  later  chapters,  we  will  conduct  proofs  of 
results  like  this. 

The  collecting  semantics  will  specify  a  superset  of  the  possible  traces  at  the 
various  program  points.  We  shall  specify  the  collecting  semantics  CS  in  the 
style  of  the  Reaching  Definitions  Analysis  in  Section  1.3;  more  precisely,  we 
shall  specify  a  twelve-tuple  of  elements  from  (P(Trace))12  by  means  of  a  set 
of  equations.  First  we  have 


CSexit 

(l)  = 

=  {tr 

:  (y,  1)  1 

tr 

6 

CS  entry 

(i)} 

CSex*t 

(2)  = 

=  {tr 

=  (*,2)| 

tr 

e 

C  Sentry 

(2)} 

CSextf 

(3)  = 

=  CSentry(3) 

CS  exit 

(4)  = 

=  {tr: 

;  (z,4)  | 

tr 

e 

CS  entry 

(4)} 

CS  exit 

(5)  = 

=  {tr: 

:  (y,5)  I 

tr 

G 

CS  entry 

(5)} 

CSex*t 

(6)  = 

-  {tr: 

(y»6)  1 

tr 

G 

CS  entry 

(6)} 

showing  how  the  assignment  statements  give  rise  to  extensions  of  the  traces. 
Here  we  write  tr  :  (x,i)  for  appending  an  element  (x,  £)  to  a  list  tr,  that 
is  ((xi.fi),---,  ( xn,£n )) :  (x ,£)  equals  ,(xn,£n),(x,t)).  Further¬ 

more,  we  have 


CSentry(2) 

=  CSe*it(l) 

CS  entry  (3) 

=:.CSeiit(2)UCSexit(5) 

CS  entry  (4) 

—  CSeztt(3) 

CSentry  (3) 

=  CSeii£(4) 

CS  entry  (6) 

=  CS  exit  (3) 

corresponding  to  the  flow  of  control  in  the  program;  more  detailed  infor¬ 
mation  about  the  value  of  the  variables  would  allow  us  to  define  the  sets 
CS  entry  (4)  and  CS  entry  (6)  more  precisely  but  the  above  definitions  are  suffi¬ 
cient  for  illustrating  the  approach.  Finally,  we  take 


CS  entry  (1)  =  {((x,  ?),  (y,  ?),  (z,  ?))} 

corresponding  to  the  fact  that  all  variables  are  uninitialised  in  the  beginning. 

In  the  manner  of  the  previous  sections  we  can  rewrite  the  above  system  of 
equations  in  the  form 

Ct  =  G(Ct) 

where  C^  is  a  twelve-tuple  of  elements  from  (V (Trace)) 12  and  where  G  is  a 
monotone  function  of  functionality: 


G  :  (P(Trace))12  ('P(Trace))12 
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Figure  1.3:  The  adjunction  (0,7). 


As  is  explained  in  Appendix  A  there  is  a  body  of  general  theory  that  ensures 
that  the  equation  in  fact  has  a  least  solution;  we  shall  write  it  as  lfp(G). 
However,  since  (P(Trace))12  is  not  finite  we  cannot  simply  use  the  methods 
of  the  previous  sections  in  order  to  construct  lfp(G). 

Galois  connections.  As  we  have  seen  the  collecting  semantics  operates 
on  sets  of  traces  whereas  the  Reaching  Definitions  Analysis  operates  on  sets  of 
pairs  of  variables  and  labels.  To  relate  these  “worlds”  we  define  an  abstraction 
function  a  and  a  concretisation  function  7  as  illustrated  in: 

7 

■p(Trace)  t  V(Var  x  Lab) 

a 

The  idea  is  that  the  abstraction  function  a  extracts  the  reachability  informa¬ 
tion  present  in  a  set  of  traces;  it  is  natural  to  define 

a(X)  =  {(x,  SRD(tr)(x))  |  x  €  Var  Air  6  X} 

where  we  exploit  the  notion  of  semantically  reaching  definitions. 

The  concretisation  function  7  then  produces  all  traces  tr  that  are  consistent 
with  the  given  reachability  information: 

7(F)  =  {tr  |  Vx  €  Var  :  (x,SRD(tr)(x))  €  F} 

Often  it  is  demanded  that  a  and  7  satisfy  the  condition 

a(X)  CF^IC  7(F) 

and  we  shall  say  that  (a,  7)  is  an  adjunction,  or  a  Galois  connection,  whenever 
this  condition  is  satisfied;  this  is  illustrated  on  Figure  1.3.  We  shall  leave  it 
to  the  reader  to  verify  that  (0,7)  as  defined  above  does  in  fact  fulfil  this 
condition. 


r. 

t 
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Induced  analysis.  We  shall  now  show  how  the  collecting  semantics 
can  be  used  to  calculate  (as  opposed  to  “guess”)  an  analysis  like  the  one  in 
Section  1.3;  we  shall  say  that  the  analysis  is  an  induced  analysis.  For  this  we 
define 


S(X  u---,X12)  =  ( a(X1),---,a(X12 )) 

=  (7(Fi  ),•••,  7(^12)) 

where  a  and  7  are  as  above  and  we  consider  the  function  d?  o  G  o  7  of  func¬ 
tionality: 

(a  o  G  o  7)  :  (V(Var  x  Lab))12  -t  (V(Vai  x  Lab))12 

This  function  defines  a  Reaching  Definitions  analysis  in  an  indirect  way.  Since 
G  is  specified  by  a  set  of  equations  (over  V (Trace))  we  can  use  a  o  G  o  7  to 
calculate  a  new  set  of  equations  (over  P(Var  x  Lab)).  We  shall  illustrate 
this  for  one  of  the  equations: 

CSeiit(4)  =  {tr  :  (z,4)  |  tr  €  CSentrv(4)} 

The  corresponding  clause  in  the  definition  of  G  is: 

<3  exit  (4)  (•  •  • ,  CS  entry  (4),  ■  •  •)  =  {tr  :  (z,  4)  |  tr  G  CSentry(4)} 

We  can  now  calculate  the  corresponding  clause  in  the  definition  of  a  o  G  o  7: 

0:(Gcxit(4)(j(-  ■  •  ,  RD entry (4),  •  V-))) 

=  a({tr  :  (z,4)  |  tr  G  y(RDentry(4))}) 

=  {(x,  SRD(tr  :  (z,4))(a:)) 

|  x  €  Var,  Vj/  €  Var  :  (y,SRD(tr)(y))  e  RDe„try(4)} 

=  {(x,SRD(tr)(x)) 

|  x  G  Var,  x  ^  z,  (x,  SRD(tr)(x))  G  RDentrv(4)}  U  {(z,  4)} 

=  (RDentry  (4)  \  {(z ,1)  |  e  G  Lab})  U  {(z,4)} 

This  clause  is  equivalent  to  the  equation  for  RD  exit  (4)  in  Section  1.3;  similar 
calculations  can  be  performed  for  the  other  clauses. 

The  least  solution.  As  explained  in  Appendix  A  the  equation  system 

R[5  =  (aoGo7)(R[5) 

has  a  least  solution;  we  shall  write  it  as  lfp(a  0  G  o  7).  It  is  interesting  to 
note  that  if  one  replaces  the  infinite  sets  Var  and  Lab  with  finite  sets  Var* 
and  Lab*  as  before,  then  the  least  fixed  point  of  a  o  G  o  7  can  be  obtained 
as  (aoGo 7)n(0)  just  as  was  the  case  for  F  previously. 

In  Exercise  1.4  we  shall  show  that  a  o  G  o  7  C  F  and  it  follows  that 
a(lfp(G))  C  lfp{a  o  G  o  7)  C  lfp(F) 


1.6  Type  and  Effect  Systems 


17 


where  the  second  inclusion  should  not  be  surprising  because  mathematical 
induction  suffices  for  showing  that  (a  o  G  o  7)n(0)  C  Fn(0).  The  above 
inclusions  just  say  that  the  least  solution  to  the  equation  system  defined  by 
a o Go 7  is  correct  with  respect  to  the  collecting  semantics,  and  similarly  that 
the  least  solution  to  the  equation  system  of  Section  1.3  is  also  correct  with 
respect  to  the  collecting  semantics.  Thus  it  follows  that  we  will  only  need  to 
show  that  the  collecting  semantics  is  correct  -  the  correctness  of  the  induced 
analysis  will  follow  for  free. 

For  some  analyses  one  is  able  to  prove  the  stronger  result  a  o  G  o  7  =  F. 
Then  the  analysis  is  optimal  (given  the  choice  of  approximate  properties  it 
operates  on)  and  clearly  lfp(a  o  G  o  7)  =  lfp(  F).  In  Exercise  1.4  we  shall 
study  whether  or  not  this  is  the  case  here. 


1.6  Type  and  Effect  Systems 

A  simple  type  system.  The  ideal  setting  for  explaining  Type  and 
Effect  Systems  is  to  consider  a  typed  functional  or  imperative  language. 
However,  even  our  simple  toy  language  can  be  considered  to  be  typed:  a 
statement  S  maps  a  state  to  a  state  (in  case  it  terminates)  and  may  therefore 
be  considered  to  have  type  £  £  where  E  denotes  the  type  of  states;  we 

write  this  as  the  judgement: 

S:£->E 

One  way  to  formalise  this  is  by  the  following  utterly  trivial  system  of  axioms 
and  inference  rules: 

[x  :=  a]*  :  E  E 
[skip]*  :  £  -4  E 

Si  :  E  — ►  E  S2  :  £  — ^  £ 

Si]  S2  :  E  — >  E 

Si  :  E  — ^  E  S2  :  E  — ^  £ 
if  [6]*  then  Si  else  S2  :  E  -)•  E 

S  :  £  -»  £ 

while  [6]*  do  S  :  E  -4  E 

Often  a  Type  and  Effect  System  can  be  viewed  as  the  amalgamation  of  two 
ingredients:  an  Effect  System  and  an  Annotated  Type  System.  In  an  Effect 
System  we  typically  have  judgements  of  the  form  S  :  E  E  where  the  effect 
(p  tells  something  about  what  happens  when  S  is  executed:  this  may  for 
example  be  which  errors  might  occur,  which  exceptions  might  be  raised,  or 
which  files  might  be  modified.  In  an  Annotated  Type  System  we  typically 
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[ass]  [x  :=  a}1'  :  RD  ->  ((RD\{(z,  t)\t£  Lab})  U  {(®,  i' )}) 
[sA:tp]  [skip]*’  :  RD  — >  RD 


[seq] 


S\  :  RDj  — t  RD2  S%  :  RD2  — t  RD3 
Si;  £2  :  RDj  — >  RD3 


Si  :  RDi  — t  RD2  S2  •  RDi  — ^  RD2 
if  [&]*  then  Si  else  S2  :  RDi  ->  RD2 


S  :  RD  -»  RD 

while  [6]*  do  S  :  RD  — >  RD 


[su6] 


S  RD2  - +  RD3 
S  i  RDi  — ^  RD4 


if  RDi  C  RD2  and  RD3  C  RD4 


Table  1.2:  Reaching  Definitions:  annotated  base  types. 


have  judgements  of  the  form  S  :  £1  ->  E2  where  the  E i  describe  certain 
properties  of  states:  this  may  for  example  be  that  a  variable  is  positive  or 
that  a  certain  invariant  is  maintained.  We  shall  first  illustrate  the  latter 
approach  for  the  While  language  and  then  illustrate  the  Effect  Systems 
using  the  functional  language. 


1.6.1  Annotated  Type  Systems 

Annotated  base  types.  To  obtain  our  first  specification  of  Reaching 
Definitions  we  shall  focus  on  a  formulation  where  the  base  types  are  anno¬ 
tated.  Here  we  will  have  judgements  of  the  form 

S  :  RDi  — ^  RD2 

where  RD^  RD2  €  P(Var  x  Lab)  are  sets  of  reaching  definitions.  Based 
on  the  trivial  axioms  and  rules  displayed  above  we  then  obtain  the  more 
interesting  ones  in  Table  1.2. 

To  explain  these  rules  let  us  first  explain  the  meaning  of  S  :  RDi  — ►  RD2  in 
terms  of  the  developments  performed  in  Section  1.3.  For  this  we  first  observe 
that  any  statement  S  will  have  one  elementary  block  at  its  entry,  denoted 
init(S),  and  one  or  more  elementary  blocks  at  its  exit,  denoted  Rnal(S);  for  a 
statement  like  if  [x<y]x  then  [x:=y]2  else  [y:=x]3  we  thus  get  init(---)  =  1 
and  fina 1(-  •  •)  =  {2, 3}. 

Our  first  (and  not  quite  successful)  attempt  at  explaining  the  meaning  of 
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5  :  RDi  -¥  Rb2  then  is  to  say  that: 

RDi  =  RDe„fry(init(5)) 

1 1  €  final(S)}  =  RD2 

This  suffices  for  explaining  the  axioms  for  assignment  and  skip:  here  the 
formulae  after  the  arrows  correspond  exactly  to  the  similar  equations  in  the 
equational  formulation  of  the  analysis  in  Section  1.3.  Also  the  rule  for  se¬ 
quencing  now  seems  rather  natural.  However,  the  rule  for  conditional  is  more 
dubious:  considering  the  statement  if  [x<y]4  then  [x:=y]2  else  [y:=x]3  once 
more,  it  seems  impossible  to  achieve  that  the  then-branch  gives  rise  to  the 
same  set  of  reaching  definitions  as  the  else-branch  does. 

Our  second  (and  successful)  attempt  at  explaining  the  intended  meaning  of 
S  :  RDi  — »  RD2  then  is  to  say  that: 

RDj  C  RDenfrv  (init(S)) 

W  €  final(S)  :  RDe*if(0  C  RD2 

This  formulation  is  somewhat  closer  to  the  development  in  the  constraint 
based  formulation  of  the  analysis  in  Section  1.3  and  it  explains  why  tne  last 
rule,  called  a  subsumption  rule ,  is  unproblematic.  Actually,  the  subsumption 
rule  will  solve  our  problem  with  the  conditional  because  even  when  the  then- 
branch  gives  a  different  set  of  reaching  definitions  than  the  else-branch  we 
can  enlarge  both  results  to  a  common  set  of  reaching  definitions.  Finally, 
consider  the  rule  for  the  iterative  Construct.  Here  we  simply  express  that  RD 
is  a  consistent  guess  concerning  what  may  reach  the  entry  and  exits  of  S  - 
this  expresses  a  fixed  point  property. 

Example  1.3  To  analyse  the  factorial  program 

[y :  =x] 1 ;  [z:=l]2;  while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y:=0]6 

of  Example  1.1  we  will  proceed  as  follows.  We  shall  write  RDf  for  the  set 
{(x,  ?),  (y,  1),  (y,  5),  (z,  2),  (z,  4)}  and  consider  the  body  of  the  while-loop. 
The  axiom  [ass]  gives 

[z:=z*y]4:  RDf  -*  {(x,  ?),  (y,  1),  (y,5),  (z,4)} 

[y:=y-l]5  :  {(x,  ?),  (y,  1),  (y,  5),  (z,4)}  -f  {(x,?),  (y,5),  (z,4)} 

so  the  rule  [seg]  gives: 

([z :  =z*y]4;  [y:=y-l]5):  RDf  ->  {(x,?),(y,5),  (z,4)} 

Now  {(x,?),(y, 5),(z, 4)}  C  RDf  so  the  subsumption  rule  gives: 

([z:=z*y]4;  [y:=y-l]5):  RDf  -»  RDf 
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[ass] 

[sfcy>] 

[seg] 

M 

[i uh] 
[su&] 


[x  :=  a]'  :  £  £ 

[skip]'  :  E  £ 

■Si  :  E  E  ^2  :  E  -^4  £ 


rd2 


5i:52  :  S  (RD1j\xJ2fuRD2>  E 


5i  :  E 


“RD/ 


E  £ 


if  [6]'  then  Si  else  S2  :  £  ■r-d]urd2>  E 

S:El£>  E 


while  [&]'  do  S  :  £  £ 

S-—~k&  £-  ax'  CX  and  RD  C  RD' 


S:£^>  £ 


Table  1.3:  Reaching  Definitions:  annotated  type  constructors. 


We  can  now  apply  the  rule  [tn/i]  and  get: 

while  [y>l]3  do  ([z:=?z*y]4;  [y:=y-l]5):  RDf  -4  RDf 

Using  the  axiom  [ass]  we  get: 

[y :  =x]J:  {(x,  ?),  (y,  ?),  (Z, ?)}  -4  {(x,  ?),  (y,  1),  (z,  ?)} 

[z :  =1]2  :  {(x,  ?),  (y,  1),  (z,  ?)}  -4  {(x,  ?),  (y,  1),  (z,  2)} 

[y:=0]6:  RDf  -4  {(x,  ?),  (y,  6),  (z,  2),  (z,  4)} 

Since  {(x,  ?),  (y,  1),  (z,  2)}  C  RDf  we  can  apply  the  rules  [seg]  and  [sm6]  to  get 


([y:=x]x;  [z:=l]2;  while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y:=0]6): 

{(x,  ?),(y,?),(z,?)}  -4  {(x,  ?),  (y,6),  (z,  2),  (z,  4)} 

corresponding  to  the  result  in  Table  1.1.  ■ 

The  system  in  Table  1 .2  suffices  for  manually  analysing  a  given  program.  To 
obtain  an  implementation  it  will  be  natural  to  extract  a  set  of  constraints 
similar  to  those  considered  in  Section  1.3,  and  then  solve  them  in  the  same 
way  as  before.  This  will  be  the  idea  behind  the  approach  taken  in  Chapter 
5. 
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Annotated  type  constructors.  Another  approach  to  Reaching  Def¬ 
initions  has  a  little  bit  of  the  flavour  of  Effect  Systems  in  that  it  is  the  type 
constructors  (arrow  in  our  case)  that  are  annotated.  Here  we  will  have  judge¬ 
ments  of  the  form 

5  :  £  — +  E 

RD 

where  X  denotes  the  set  of  variables  that  definitely  will  be  assigned  in  S  and 
RD  denotes  the  set  of  reaching  definitions  that  S  might  produce.  The  axioms 
and  rules  are  shown  in  Table  1.3  and  are  explained  below. 

The  axiom  for  assignment  simply  expresses  that  the  variable  x  definitely  will 
be  assigned  and  that  the  reaching  definition  (x,  t)  is  produced.  In  the  rule 
for  sequencing  the  notation  RD  \  X  means  {(z, i)  S  RD  |  x  £  X}.  The 
rule  expresses  that  we  take  the  union  of  the  reaching  definitions  after  having 
removed  entries  from  Si  that  are  definitely  redefined  in  SV  Also  we  take  the 
union  of  the  two  sets  of  assigned  variables.  In  the  rule  for  conditional  we 
take  the  union  of  information  about  reaching  definitions  whereas  we  take  the 
intersection  (rather  than  the  union)  of  the  assigned  variables  because  we  are 
not  completely  sure  what  path  was  taken  through  the  conditional.  A  similar 
comment  holds  for  the  rule  for  the  while-loop;  here  we  can  think  of  0  as  the 
intersection  between  0  (when  the  body  is  not  executed)  and  X. 

We  have  included  a  subsumption  rule  because  this  is  normally  the  case  for 
such  systems  as  we  shall  see  in  Chapter  5.  However,  in  the  system  above  there 
is  little  need  for  it,  and  if  one  excludes  it  then  implementation  becomes  very 
straightforward:  simply  perform  a  syntax  directed  traversal  of  the  program 
where  the  sets  X  and  RD  are  computed  for  each  subprogram. 

Example  1.4  Let  us  once  again  consider  the  analysis  of  the  factorial  pro¬ 
gram 


[y:=x]x;  [z:=l]2;  while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y :  =0]6 
For  the  body  of  the  while-loop  we  get 

[z:=z*y]4:  E  s 

[y:-y-»]‘:  S  -A*  E 

so  the  rule  [set/]  gives: 

([z:=z*y]4;  [y:=y-l]5):  E  <(y ,fe(z},4)}>  s 
We  can  now  apply  the  rule  [wh]  and  get: 

while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5):  E  {(7,5)?(g,4;j]^  E 
In  a  similar  way  we  get 
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«y:-x]';  [z:=l]2):  £  E 

S  1&*  £ 

so  using  the  rule  [seg]  we  obtain 

([y^x]1;  [z:=l]2;  while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y  :=0]6): 

S  {(y,6),(z!2),(z,4)}>  S 

showing  that  the  program  definitely  will  assign  to  y  and  z  and  that  the  final 
value  of  y  will  be  assigned  at  6  and  the  final  value  of  z  at  2  or  4.  ■ 

Compared  with  the  previous  specifications  of  Reaching  Definitions  analy¬ 
sis  the  flavour  of  Table  1.3  is  rather  different:  the  analysis  of  a  statement 
expresses  how  information  present  at  the  entry  will  be  modified  by  the  state¬ 
ment  -  we  may  therefore  view  the  specification  as  a  higher-order  formulation 
of  Reaching  Definitions  analysis. 

1.6.2  Effect  Systems 

A  simple  type  system.  To  give  the  flavour  of  Effect  Systems  let 
us  once  more  turn  to  the  functional  language.  As  above,  the  idea  is  to 
annotate  a  traditional  type  system  .with  analysis  information,  so  let  us  start 
by  presenting  a  simple  type  system  for  a  language  with  variables  x,  function 
abstraction  fn*  x  =>  e  (where  n  is  the  name  of  the  abstraction),  and  function 
application  e\  e2.  The  judgements  have  the  firm 

H-e:r 

where  T  is  a  type  environment  that  gives  types  to  all  free  variables  of  e  and 
t  is  the  type  of  e.  For  simplicity  we  shall  assume  that  types  are  either  base 
types  as  int  and  bool  or  they  are  function  types  written  t\  — ►  r2.  The  type 
system  is  given  by  the  following  axioms  and  rules: 

T  h  x  :  tx  if  r(x)  =  tx 

F[J  HT,]he:r 
T  I-  f  n„  x  =>  e  :  tx  ->  r 

r  1-  ei  :  t2  -»  r,  r  I-  e2  :  r2 
n-ei  e2:r 

So  the  axiom  for  variables  just  expresses  that  the  type  of  x  is  obtained  from 
the  assumptions  of  the  type  environment.  The  rule  for  function  abstrac¬ 
tion  requires  that  we  “guess”  a  type  tx  for  the  formal  parameter  x  and  we 
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determine  the  type  of  the  body  of  the  abstraction  under  that  additional  as¬ 
sumption.  The  rule  for  function  application  requires  that  we  determine  the 
type  of  the  operator  as  well  as  the  argument  and  it  implicitly  expresses  that 
the  operator  must  have  a  function  type  by  requiring  the  type  of  ei  to  have 
the  form  r2  ->  r.  Furthermore  the  two  occurrences  of  r2  in  the  rule  implicitly 
express  that  the  type  of  the  actual  parameter  must  equal  the  type  expected 
by  the  formal  parameter  of  the  function. 

Example  1.5  Consider  the  following  version  of  the  program  of  Example 
1.2 


(fnx  x  =>  x)  (fny  y  =>  y) 

where  we  now  have  given  fn  x  =>  x  the  name  X  and  fn  y  =>  y  the  name 
Y.  To  see  that  this  program  has  type  int  ->  int  we  first  observe  that 
[y  int]  I-  y  :  int  so: 

[  ]  h  fny  y  =>  y  :  int  int 
Similarly,  we  have  [x  i->  int  — »  int]  h  x  :  int  ->  int  so: 

[  ]  h  fnx  x  =>  x  :  (int  — >  int)  — >  (int  — >  int) 

The  rule  for  application  then  gives: 

[  ]  h  (fnx  x  =>  x)  "(fnY  y  =>  y)  :  int  -t  int  m 

Effects.  The  analysis  we  shall  consider  is  a  Call-tracking  Analysis: 

For  each  subexpression,  which  function  abstractions  may  be  ap¬ 
plied  during  its  evaluation. 

The  set  of  function  names  constitutes  the  effect  of  the  subexpression.  To 
determine  this  information  we  shall  annotate  the  function  types  with  their 

latent  effect  so  we  shall  e.g.  write  int  int  for  the  type  of  a  function 
mapping  integers  to  integers  and  with  effect  {X}  meaning  that  when  execut¬ 
ing  the  function  it  may  apply  the  function  named  X.  More  generally,  the 
annotated  types  r  will  either  be  base  types  or  they  will  have  the  form 

~  <p  ~ 

n  — >  r2 


where  ip  is  the  effect,  i.e.  the  names  of  the  function  abstractions  that  we 
might  apply  when  applying  a  function  of  this  type. 

We  specify  the  analysis  using  judgements  of  the  form 

T  h  e  :  t  &  <p 


Yi 
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[uar] 

r  h  x  :  tx  &  0  if  T(x)  =  ?x 

IM 

r[x  tx\  I-  e  :  f  k.  p 

T  h  fnw  x  =>  e  :  tx  f  &  0 

[app] 

f  1-  ex  :  ?2  ^4  t  &  < pi  f  h  e2  :  r2  &  ^2 

T  1-  ei  e2  :  f  &  <p\  U  ipi  U  <p 

Table  1.4:  Call-tracking  Analysis:  Effect  System. 


where  T  is  the  type  environment  that  now  gives  the  annotated  type  of  all 
free  variables,  f  is  the  annotated  type  of  e,  and  ip  is  the  effect  of  evaluating 
e.  The  analysis  is  specified  by  the  axioms  and  rules  in  Table  1.4  which  will 
be  explained  below. 

In  the  axiom  [var]  for  variables  we  produce  an  empty  effect  because  we  as¬ 
sume  that  the  parameter  mechanism  is  call-by-value  so  no  evaluation  takes 
place  when  mentioning  a  variable.  Similarly,  in  the  rule  [fn]  for  function  ab¬ 
stractions  we  produce  an  empty  effect:  no  evaluation  takes  place  because  we 
only  construct  a  closure.  The  body  of  the  abstraction  is  analysed  in  order  to 
determine  its  annotated  type  and  effect.  This  information  is  needed  to  anno¬ 
tate  the  function  arrow:  all  the  names  of  functions  in  the  effect  of  the  body 
and  the  name  of  the  abstraction  itself  may  be  involved  when  this  particular 
abstraction  is  applied. 

Next,  consider  the  rule  [ app ]  for  function  application  e.\  e 2.  Here  we  obtain 
annotated  types  and  effects  from  the  operator  e\  as  well  as  the  operand  e2. 
The  effect  of  the  application  will  contain  the  effect  <pi  of  the  operator  (because 
we  have  to  evaluate  it  before  the  application  can  take  place),  the  effect  p>2  of 
the  operand  (because  we  employ  a  call-by-value  semantics  so  this  expression 
has  to  be  evaluated  too)  and  finally  we  need  the  effect  ip  of  the  function  being 
applied.  But  this  is  exactly  the  information  given  by  the  annotation  of  the 
arrow  in  the  type  r2  -^4  f  of  the  operand.  Hence  we  produce  the  union  of 
these  three  sets  as  the  overall  effect  of  the  application. 

Example  1.6  Returning  to  the  program  of  Example  1.5  we  have: 

[  ]  h  f  ny  y  =>  y  :  int  -^—4  int  &  0 

[  ]  h  fnx  x  =>  x  :  (int  -  4  int)  (int  -  4  int)  &  0 

[  ]  b  (fnx  x  =>  x)  (fny  y  =>  y)  :  int  ——4  int  &  {X} 

This  shows  that  our  example  program  may  (in  fact  it  will)  apply  the  function 
fn  x  =>  x  but  that  it  will  not  apply  the  function  fn  y  =>  y.  ■ 
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INPUT:  Example  equations  for  Reaching  Definitions 

OUTPUT:  The  least  solution:  r6 

METHOD:  Step  1:  Initialisation 

RDi:=0;  •  •  • ;  RDi2:=0 

Step  2:  Iteration 

while  RD.,-  ^  Fj(RDi,  •  •  • ,  RDi2)  for  some  j 
do  RDj:=jFj(RDi,  •  •  • ,  RD12) 


Table  1.5:  Chaotic  Iteration  for  Reaching  Definitions. 


For  a  more  general  language  we  will  also  need  to  introduce  some  form  of 
subsumption  rule  in  the  manner  of  Tables  1.2  and  1.3;  there  are  different 
approaches  to  this  and  we  shall  return  to  this  later.  Effect  Systems  are 
often  implemented  as  extension  of  type  inference  algorithms  and  depending 
on  the  form  of  the  effects  it  may  be  possible  to  calculate  them  on  the  fly; 
alternatively,  sets  of  constraints  can  be  generated  and  solved  subsequently. 
We  refer  to  Chapter  5  for  more  details. 


1.7  Algorithms 

Let  us  now  reconsider  the  problem  of  computing  the  least  solution  to  the 
program  analysis  problems  considered  in  Data  Flow  Analysis  and  Control 
Flow  Analysis. 

Recall  from  Section  1.3  that  we  consider  twelve-tuples  R6  G  (7>(Var*  x 
Lab*))12  of  pairs  of  variables  and  labels  where  each  label  indicates  an  ele¬ 
mentary  block  in  which  the  corresponding  variable  was  last  assigned.  The 
equation  or  constraint  system  gives  rise  to  demanding  the  least  solution  to  an 
equation  R&  =  F(rB)  or  inclusion  RE^  □  F(R^)  where  F  is  a  monotone  func¬ 
tion  over  (P(Var*  x  Lab*))12.  Due  to  the  finiteness  of  (7?(Var*  x  Lab*))12 
the  desired  solution  is  in  both  cases  obtainable  as  F"(0)  for  any  n  such  that 
Fn+1  (0)  =  Fn(0)  and  we  know  that  such  n  does  in  fact  exist. 

Chaotic  Iteration.  Naively  implementing  the  above  procedure  soon 
turns  out  to  require  an  overwhelming  amount  of  work.  In  later  chapters  we 
shall  see  much  more  efficient  algorithms  and  in  this  section  we  shall  illustrate 
the  principle  of  Chaotic  Iteration  that  lies  at  the  heart  of  many  of  them.  For 
this  let  us  write 
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F(R6)  =  (Fi(R^),  •  •  • ,  Fi2(rS)) 

and  consider  the  non-deterministic  algorithm  in  Table  1.5.  It  is  immediate 
that  there  exists  j  such  that  RDj  ^  F,(RDx,  ■  •  • ,  RD12)  if  and  only  if  ^ 
F(R^).  Hence  if  the  algorithm  terminates  it  will  produce  a  fixed  point  of  F\ 
that  is,  a  solution  to  the  desired  equations  or  constraints. 

Properties  of  the  algorithm.  To  further  analyse  the  algorithm  we 
shall  exploit  that 

0  C  R&  C  F(r3)  C  Fn(0) 

holds  at  all  points  in  the  algorithm  (where  n  is  determined  by  Fn+1  (0)  = 
Fn(0)):  it  clearly  holds  initially  and  as  will  be  shown  in  Exercise  1.6  it  is 
maintained  during  iteration.  This  means  that  if  the  algorithm  terminates  we 
will  have  obtained  not  only  a  fixed  point  of  F  but  in  fact  the  least  fixed  point 
(i.e.  Fn(0)). 

To  see  that  the  algorithm  terminates  note  that  if  j  satisfies 

RDj  ^  Fj(RD1(  •  •  • ,  RD12) 

then  in  fact  RDy  C  F,(RDi,  •  •  • ,  RD12)  and  hence  the  size  of  r6  increases  by 
at  least  one  as  we  perform  each  iteration.  This  ensures  termination  since  we 
assumed  that  (F(Var*  x  Lab*))12  is  finite. 

The  above  algorithm  is  suitable  for  manually  solving  data  flow  equations  and 
constraint  systems.  To  obtain  an  algorithm  that  is  suitable  for  implemen¬ 
tation  we  need  to  give  more  details  about  the  choice  of  j  so  as  to  avoid  an 
extensive  search  for  the  value;  we  shall  return  to  this  in  Chapters  2  and  6. 


1.8  Transformations 

A  major  application  of  program  analysis  is  to  transform  the  program  (at  the 
source  level  or  at  some  intermediate  level  inside  a  compiler)  so  as  to  obtain 
better  performance.  To  illustrate  the  ideas  we  shall  show  how  Reaching  Defi¬ 
nitions  can  be  used  to  perform  a  transformation  known  as  Constant  Folding. 
There  axe  two  ingredients  in  this.  One  is  to  replace  the  use  of  a  variable  in 
some  expression  by  a  constant  if  it  is  known  that  the  value  of  the  variable  will 
always  be  that  constant.  The  other  is  to  simplify  an  expression  by  partially 
evaluating  it:  subexpressions  that  contain  no  variables  can  be  evaluated. 

Source  to  source  transformation.  Consider  a  program  5*  and  let 
RD  be  a  solution  (preferable  the  least)  to  the  Reaching  Definitions  Analysis 
for  5*.  For  a  sub-statement  S  of  5*  we  shall  now  describe  how  to  transform 
it  into  a  “better”  statement  S'.  We  do  so  by  means  of  judgements  of  the 
form 


RDF  5  D>  S' 
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[assi] 

RD  1-  [x  :=  a)1  t>  [ x  :=  a[y  i-t  n]]* 

/  y  €  FV(a)  A  (»,?)*  RDentrv(f)  A 

11  {  V(z,e')eRDentTy(e):(z  =  y^[--Y 

is  [y  :=  n]*') 

[ass2] 

RD  F  [x  :=  a}1  >  [a;  :=  n ]l 

if  FV(a)  =  0  A  a  $  Num  A  a  evaluates  to  n 

[seqi] 

RD  1-  Si  C>  S[ 

RD  b  Si; 52  >  S[; 52 

[se<fc] 

RDh52  >  S'2 

RDh5i;52  >  5i;52 

[*/i] 

RD  (-  Si  >  S[ 

RD  F  if  [6]<  then  Si  else  S2  >  if  [6]^  then  S[ 

else  52 

m 

RD  h  52  >  S'2 

RD  F  if  [6]*  then  Si  else  S2  >  if  [6]f  then  Si 

else  S2 

[wh\ 

RD  F  S  o  S' 

RD  F  while  [6]/  do  5  O  while  [6]*  do  S' 

Tkble  1.6:  Constant  Folding  transformation. 


expressing  one  step  of  the  transformation  process.  We  may  define  the  trans¬ 
formation  using  the  axioms  and  rules  in  Table  1.6;  they  are  explained  below. 

The  first  axiom  [a.ss:]  expresses  the  first  ingredient  in  Constant  Folding  as 
explained  above  -  the  use  of  a  variable  can  be  replaced  with  a  constant  if  it  is 
known  that  the  variable  always  will  be  that  constant;  here  we  write  a[y  h->  n] 
for  the  expression  that  is  as  a  except  that  all  occurrences  of  y  have  been 
replaced  by  n;  also  we  write  FV(a)  for  the  set  of  variables  occurring  in  a. 

The  second  axiom  [ass2]  expresses  the  second  ingredient  of  the  transformation 
-  expressions  can  be  partially  evaluated;  it  uses  the  fact  that  if  an  expression 
contains  no  variables  then  it  will  always  evaluate  to  the  same  value. 

The  five  rules  in  Table  1.6  simply  say  that  if  we  can  transform  a  sub-statement 
then  we  can  transform  the  statement  itself.  Note  that  the  rules  (e.g.  [ seq J 
and  [sey2])  do  not  prescribe  a  specific  transformation  order  and  hence  many 
different  transformation  sequences  may  exist.  Also  note  that  the  relation 
RD  F  •  D>  -  is  neither  reflexive  nor  transitive  because  there  are  no  rules  that 
forces  it  to  be  so.  Hence  we  shall  often  want  to  perform  an  entire  sequence 
of  transformations. 
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Example  1.7  To  illustrate  the  use  of  the  transformation  consider  the  pro¬ 
gram: 


[x:=10]x;  [y:=x+10]2;  [z:=y+10]3 


The  least  solution  to  the  Reaching  Definitions  Analysis  for  this  program  is: 


RDeniry(l)  =  {(x,?),(y,?),(z,?)} 

RD«tt(l)  =  {(x,  1),  (y,?),  (z,  ?)} 

RDenfry(2)  =  {(x,  1),  (y,  ?),  (z,  ?)} 

RDe«t(2)  =  {(x,l),(y,2),(z,?)} 

RDentry  (3)  =  {(x,  1),  (y,  2),  (z,  ?)} 

RD«itt(3)  =  {(x,  1),  (y,  2),  (z,  3)} 


Let  us  now  see  how  to  transform  the  program.  From  the  axiom  [assi]  we 
have 

RD  I-  [y:=x+10]2  >  [y:=10+10]2 
and  therefore  the  rules  for  sequencing  gives: 

RD  h  [x:=10]1;[y:=x+10]2;[z:=y+10]3  t>  [x.^10]1;  [y:=10+10]2;  [z:=y+10]3 
We  can  now  continue  and  obtain  the  following  transformation  sequence: 

RD  h  [x :  =10]1;  [y:=x+10]2;  [z:=y+10]3 

>  [x :  =10]1;  [y  :=10+10]2;  [z:=y+10]3 

>  [x:=10l1.;(y:=20]2;[z:=y+10]3 

>  [x :  =  1 0] 1 ;  [y :  =20]2 ;  [z:=20+10]3 

t>  [x:=10]1;[y:=20)2;[z:=30]3 

after  which  no  more  steps  are  possible.  Another  transformation  sequence  is 

RD  h  [x:-10]*;[y:=x+10]2;[z:«y+10]3 
t>  [x :  =10]1 ;  [y :  =10+ 10]2 ;  [z :  =y+10]3 
D>  [x :  —  1 0] 1  j  [y :  =10+10]2 ;  [z :  =10+10+10]3 

t>  [x:=10]1;[y:=10+10]2;[z:=30]3 
C>  [x:=10]1;[y:=20]2;[z:=30]3 


which,  in  this  particular  case,  yields  the  same  resulting  program.  ■ 

Successive  transformations.  The  above  example  shows  that  we 
shall  want  to  perform  many  successive  transformations: 

RD  I-  Si  >  S2  C>  •  •  •  >  Sn+i 

This  could  be  costly  because  once  Si  has  been  transformed  into  S2  we  might 
have  to  recompute  Reaching  Definitions  Analysis  for  S2  before  the  trans¬ 
formation  can  be  used  to  transform  it  into  S3  etc.  It  turns  out  that  it  is 
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sometimes  possible  to  use  the  analysis  for  Si  to  obtain  a  reasonable  analysis 
for  S2  without  performing  the  analysis  from  scratch.  In  the  case  of  Reaching 
Definitions  and  Constant  Folding  this  is  very  easy:  if  RD  is  a  solution  to 
Reaching  Definitions  for  Si  and  RD  b  Si  C>  Si+1  then  RD  is  also  a  solution  to 
Reaching  Definitions  for  Sj+i  -  intuitively,  the  reason  is  that  the  transforma¬ 
tion  only  changed  things  that  were  not  observed  by  the  Reaching  Definitions 
Analysis. 


Concluding  Remarks 

In  this  chapter  we  have  briefly  illustrated  a  few  approaches  (but  by  no  means 
all)  to  program  analysis.  Clearly  there  are  many  differences  between  the  four 
approaches.  However,  the  main  aim  of  the  chapter  has  been  to  suggest  that 
there  are  also  more  similarities  than  one  would  perhaps  have  expected  at 
first  sight:  in  particular,  the  interplay  between  the  use  of  equations  versus 
constraints.  It  is  also  interesting  to  note  that  some  of  the  techniques  touched 
upon  in  this  chapter  have  close  connections  to  other  approaches  to  reasoning 
about  programs;  especially,  some  versions  of  Annotated  Type  Systems  are 
closely  related  to  Hoare’s  logic  for  partial  correctness  assertions. 

As  mentioned  earlier,  the  approaches  to  program  analysis  covered  in  this  book 
are  semantics  based  rather  than  semantics  directed.  The  semantics  directed 
approaches  include  the  denotatioftal  based  approaches  [18,  66,  87,  89]  and 
logic  based  approaches  [12,  13,  61,  62]. 


Mini  Projects 

Mini  Project  1.1  Correctness  of  Reaching  Definitions 

In  this  mini  project  we  shall  increase  our  faith  in  the  Type  and  Effect  System 
of  Table  1.3  by  proving  that  it  is  correct.  This  requires  knowledge  of  regular 
expressions  and  homomorphisms  to  the  extent  covered  in  Appendix  C. 

First  we  shall  show  how  to  associate  a  regular  expression  with  each  state¬ 
ment.  We  define  a  function  S  such  that  S(S)  is  a  regular  expression  for  each 
statement  S  €  Stmt.  It  is  defined  by  structural  induction  (see  Appendix  B) 
as  follows: 


<S([x:=o]<) 
5([skip]') 
S(Si;S2) 
S( if  [6]*  then  Si  else  S2) 


1 1 
'X 

A 

S(Si)  •  S(S2) 
S(S1)  +  S(S2) 
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<S(while  b  do  5)  =  (5(5))* 

The  alphabet  is  {!£  |  x  €  Var*,  i  e  Lab*}  where  Var*  and  Lab*  are  finite 
and  non-empty  sets  that  contain  all  the  variables  and  labels,  respectively,  of 
the  statement  5*  of  interest.  As  an  example,  for  5*  being 

if  [xX)]1  then  [x:=x+l]2  else  ([x:=x+2]3; [x:=x+3]4) 

we  have  5(5*)  =!2  +  (!3  •  !*). 

Correctness  of  X.  To  show  the  correctness  of  the  X  component  in 
5  :  E  £  we  shall  for  each  y  £  Var*  define  a  homomorphism 

hy  '■  V-x  \  x  ^  Var*,£  £  Lab*}  — >  {!}* 


as  follows: 


if  y  =  x 
if  y^x 


As  an  example  /ii(5(5*))  =  !  +  (!•!)  and  /iy(5(5*))  =  A  using  that  A- A  =  A 
and  A  +  A  =  A.  Next  we  write 


hy(S(S))  c  !  •  !• 

to  mean  that  the  language  £[hy(S(S))]  defined  by  the  regular  expression 
hy(S(S))  is  a  subset  of  the  language  £[!  •  !*]  defined  by  !  •  !*;  this  is  equivalent 
to 

^3w  £  C[hy(S(S))  1  :  hy(w)  =  A 
and  intuitively  says  that  y  is  always  assigned  in  5.  Prove  that 

if  5  :  E  E  and  y  £  X  then  hy(S(S))  C  !  •  !* 

by  induction  on  the  shape  of  the  inference  tree  establishing  5  :  E  E 

(see  Appendix  B  for  an  introduction  to  the  proof  principle). 

Correctness  of  RD.  To  show  the  correctness  of  the  RD  component 
in  5  :  E  -  ^  >  £  we  shall  for  each  y  £  Var*  and  £'  £  Lab*  define  a 

homomorphism 

h1’  :{\(x\xe  Var*,  £e  Lab*}  -+  {!,?}* 

as  follows: 

f  !  if  y  =  x  A  l  =  e 

hey(!i)  =  <  ?  ify  =  *  A  l±t 
[a  if  y  ^  x 

As  an  example  h2(5(5*))  =  !  +  (?•?)  and  h®(5(5*))  =  A.  Next 
<(5(5))  C  ((!+?)*■?)  +  A 
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is  equivalent  to 

-0 w  6  £[5(5)|  :  hy  ( w )  ends  in  ! 

and  intuitively  means  than  the  last  assignment  to  y  could  not  have  been 
performed  at  the  statement  labelled  l'.  Prove  that 

if  5  :  E  E  and  (v,f)  0  RD  then  hey'(S(S))  C  ((!+?)*  •  ?)  +  A 

by  induction  on  the  shape  of  the  inference  tree  establishing  5  :  E  E.  ■ 


Exercises 

Exercise  1.1  A  variant  of  Reaching  Definitions  replaces  RD  6  V(Var  x 
Lab)  by  RL  G  'P(Lab);  the  idea  is  that  given  the  program,  a  label  should 
suffice  for  finding  the  variables  that  may  be  assigned  in  some  elementary 
block  bearing  that  label.  Use  this  as  the  basis  for  modifying  the  equation 
system  given  in  Section  1.3  for  R[5  to  an  equation  system  for  RL.  (Hint: 
It  may  be  appropriate  to  think  of  RD  =  {(a?i,  ?),•••,  (x„,  ?)}  as  meaning 
RD  =  {(*!,?.,),. ••,(*„,?-«)}  311(1  then  use  RL  =  ••»?*„}•)  ■ 

Exercise  1.2  Show  that  the  solution  displayed  for  the  Control  Flow  Anal¬ 
ysis  in  Section  1.4  is  a  solution.  Also  show  that  it  isjn  fact  the  least  solution. 
(Hint:  Consider  the  demands  on  C(2),  C(4),  p(x),  C(l)  and  C(5).)  ■ 

Exercise  1.3  Show  that  if  (0,7)  is  a  Galois  connection  then  a  uniquely 
determines  7  (meaning  that  if  also  (a,Y)  is  a  Galois  connection  then  7  =  7') 
and  similarly  that  7  uniquely  determines  a.  ■ 

Exercise  1.4  For  F  as  in  Section  1.3  and  G  as  in  Section  1.5  show  that 
a  o  G  o  7  C  F\  this  involves  showing  that 

a(Gi(7(RD1),  •  •  ■  ,7(RDh)))  C  ^(RDx,  •  •  • ,  RD12) 

for  all  j  and  (RDi,  •  •  • ,  RD12).  Determine  whether  or  not  F  =  a  o  G  o  7.  ■ 

Exercise  1.5  Consider  the  Annotated  Type  System  for  Reaching  Defini¬ 
tions  defined  in  Table  1.2  in  Section  1.6  and  suppose  that  we  want  to  stick 
to  the  first  (and  unsuccessful)  explanation  of  what  5  :  RDi  -¥  RD2  means  in 
terms  of  Data  Flow  Analysis.  Can  you  change  Table  1.2  (by  modifying  or 
removing  axioms  and  rules)  such  that  this  becomes  possible?  ■ 
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Exercise  1.6  Consider  the  Chaotic  Iteration  algorithm  of  Section  1.7  and 
suppose  that 

0  C  RS  C  F(r6)  C  Fn(0)  =  Fn+1(0) 

holds  immediately  before  the  assignment  to  RD^;  show  that  is  also  holds 
afterwards.  (Hint:  Write  r6  for  (RDi,  •  •  •  ,Fj(r3),  •  •  ■ ,  RD12)  and  use  the 
monotonicity  of  F  and  R^  C  F(R^)  to  establish  that  R[5  C  Rf^  C  F(R^)  C 
F(Rfi').)  . 

Exercise  1.7  Use  the  Chaotic  Iteration  scheme  of  Section  1.7  to  show 
that  the  information  displayed  in  Table  1.1  is  in  fact  the  least  fixed  point  of 
the  function  F  defined  in  Section  1.3.  ■ 

Exercise  1.8  Consider  the  following  program 

[a:*!.]1; while  [x>0]2  do  ([z:=z*y]3;  [x:=x-l]4) 

computing  the  x-th  power  of  the  number  stored  in  y.  Formulate  a  system 
of  data  flow  equations  in  the  manner  of  Section  1.3.  Next  use  the  Chaotic 
Iteration  strategy  of  Section  1.7  to  compute  the  least  solution  and  present  it 
in  a  table  (like  Table  1.1).  ■ 

Exercise  1.9  Perform  Constant  Folding  upon  the  program 
[x:=10]x;  [y:=x+10]2;[z:=y+x]3 

so  as  to  obtain 

[x :  =  1 0] 1 ;  [y:=20]2;  [z:=30]3 

How  many  ways  of  obtaining  the  result  are  there?  ■ 

Exercise  1.10  The  specification  of  Constant  Folding  in  Section  1.8  only 
considers  arithmetic  expressions.  Extend  it  to  deal  also  with  boolean  expres¬ 
sions.  Consider  adding  axioms  like 

RD  h  ([skip]*;  5)  t>  5 

RD  h  (if  [true]*  then  S\  else  S2)  >  S\ 
and  discuss  what  complications  arise.  ■ 

Exercise  1.11  Consider  adding  the  axiom 
RD  I-  [ x  :=  a]*  t>  [r  :=  a[y  ►-*  a']]* 

/  yeFV(a)  A  {y,  ?)  $  RDentry(^)  A 
1  V(*,0  €  RD enfry (£)  :  (»  =  «  =»  [•••]*'  is  [y  :=  a'}1') 

to  the  specification  of  Constant  Folding  given  in  Section  1.8  and  discuss 
whether  or  not  this  is  a  good  idea.  ■ 


Chapter  2 


Data  Flow  Analysis 


In  this  chapter  we  introduce  techniques  for  Data  Flow  Analysis.  Data  Flow 
Analysis  is  the  traditional  form  of  program  analysis  which  is  described  in 
many  textbooks  on  compiler  writing.  We  will  present  analyses  for  the  simple 
imperative  language  While  that  was  introduced  in  Chapter  1.  This  includes 
a  number  of  classical  Data  Flow  Analyses:  Available  Expressions,  Reaching 
Definitions,  Very  Busy  Expressions  and  Live  Variables.  We  introduce  an 
operational  semantics  for  While  and  demonstrate  the  correctness  of  the  Live 
Variables  Analysis.  We  then  present  the  notion  of  Monotone  Frameworks 
and  show  how  the  examples  may  be  recast  as  such  frameworks.  We  continue 
by  presenting  a  worklist  algorithm  for  solving  flow  equations  and  we  study 
its  termination  and  correctness  properties.  The  chapter  concludes  with  a 
presentation  of  some  advanced  topics,  including  Interprocedural  Data  Flow 
Analysis  and  Shape  Analysis. 


2.1  Intraprocedural  Analysis 

In  this  section  we  present  a  number  of  example  Data  Flow  Analyses  for 
the  While  language.  The  analyses  are  each  defined  by  pairs  of  functions 
that  map  labels  to  the  appropriate  sets;  one  function  in  each  pair  specifies 
information  that  is  true  on  entry  to  the  block,  the  second  specifies  information 
that  is  true  at  the  exit. 

Initial  and  final  labels.  When  presenting  examples  of  Data  Flow 
Analyses  we  will  use  a  number  of  operations  on  programs  and  labels.  The 
first  of  these  is 

init :  Stmt  — »  Lab 

which  returns  the  initial  label  of  a  statement: 
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init([x  :=  a]*) 
init([skip]*) 
init(Si ;  S2) 
ini t (if  [6]*  then  Si  else  S2) 
init(while  [6]*  do  S) 

We  will  also  need  a  function 


l 

l 

init(Si ) 

l 

t 


final :  Stmt  ->  T*(Lab) 


which  returns  the  set  of  final  labels  in  a  statement;  whereas  a  sequence  of 
statements  has  a  single  entry,  it  may  have  multiple  exits  (as  for  example  in 
the  conditional): 


final([x  :=  a]*) 
/mal([skip]*) 
fina/(Si;S2) 
£nal(if  [6]*  then  Si  else  S2) 
finaJ(while  [&]*  do  S) 


w 

m 

final(S2) 

final(Si)  Ufinal(S2) 

m 


Note  that  the  while-loop  terminates  immediately  after  the  test  has  evaluated 
to  false. 

Blocks.  To  access  the  statements  or  test  associated  with  a  label  in  a 
program  we  use  the  function 


blocks  :  Stmt  — >  P(Blocks) 

where  Blocks  is  the  set  of  statements,  or  elementary  blocks,  of  the  form 
[x:=a]*  or  [skip]*  as  well  as  the  set  of  tests  of  the  form  [6]*.  It  is  defined  as 
follows: 


blocks([x  :=  a]*) 
bIocks([skip]*) 
blocks(Si ;  S2) 
blocks( if  [ b ]*  then  Si  else  S2) 
blocks( while  [6]*  do  S) 


{[x  :=  a]*} 

{[skip]*} 

blocks(Si)  U  blocks(S2 ) 

{[6]*}  u  blocks(Si)  U  blocks(S2 ) 
{[6]*}  U  blocks(S) 


Then  the  set  of  labels  occurring  in  a  program  is  given  by 


labels  :  Stmt  — >  'P(Lab) 


where 

-  labels(S)  =  {i  \  [B]1  E  blocks(S)} 
Clearly  init(S)  €  labels(S)  and  final(S)  C  labels(S). 
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Flows  and  reverse  flows.  We  will  need  to  operate  on  edges,  or  flows , 
between  labels  in  a  statement.  We  define  a  function 

flow :  Stmt  ->  P(Lab  x  Lab) 

which  maps  statements  to  sets  of  flows: 

flow([x  :=  a]*)  =  0 

flow([skip]*)  =  0 

flow(Si ;  S2)  =  Bow(S\ )  U  fiow(S2) 

U{{£,init{S2))  1 1  G  finai(Si)} 
flow( if  [bY  then  Si  else  S2)  =  Bow(Si)  U  flow(S2) 

U{(/,  init(Si)),  (£,  init(S2))} 
flow(while  [6]^  do  S)  =  flow(S)  U  {(f,  init(S))} 

U{(f  ,£)  1 1'  e  Gnal(S)} 

Thus  labels(S)  and  flow(S)  will  be  a  representation  of  the  flow  graph  of  S. 

Example  2.1  Consider  the  following  program,  power,  computing  the  x-th 
power  of  the  number  stored  in  y: 

[z:=l]1;while  [x>0]2  do  ([z:=z*y]3;  [x:=x-l]4) 

We  have  inifc(power)  =  1,  finai(power)  =  {2}  and  labels(power)  =  (1,2, 3, 4}. 
The  function  Bow  produces  the  following  set 

{(1,2),  (2,3),  (3,4),  (4,2)} 

which  corresponds  to  the  flow  graph  in  Figure  2.1.  ■ 

The  function  Bow  is  used  in  the  formulation  of  forward  analyses.  Clearly 
init(S)  is  the  (unique)  entry  node  for  the  flow  graph  with  nodes  labels(S) 
and  edges  Bow(S).  Also 

labels(S)  =  { init{S )}  U  {£  |  (£,£')  €  Bow(S)}  U  {£'  \  {£,£')  G  flow(S)} 

and  for  composite  statements  (meaning  those  not  simply  of  the  form  [i?]*) 
the  equation  remains  true  when  removing  the  {init(S)}  component. 

In  order  to  formulate  backward  analyses  we  require  a  function  that  computes 
reverse  flows : 

flow** :  Stmt  — >  ^(Lab  x  Lab) 

It  is  defined  by: 

flowR(S)  =  {{£,£')  |  (£',£)  G  flow(5)} 
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Figure  2.1:  Flow  graph  for  the  power  program. 


Example  2.2  For  the  power  program  of  Example  2.1,  flow R  produces 

{(2,1),  (2, 4),  (3, 2),  (4, 3)} 

which  corresponds  to  a  modified  version  of  the  flow  graph  in  Figure  2.1  where 
the  direction  of  the  arcs  has  been  reversed.  ■ 

In  case  Rnal(S)  contains  just  one  element  that  will  be  the  unique  entry  node 
for  the  flow  graph  with  nodes  labels(S)  and  edges  flowR(5).  Also 

labels(S)  =  Rnal{S )  U  {£  |  €  flowR(5)}  U  {£'  |  (£,£')  G  flowR(5)} 

and  for  composite  statements  the  equation  remains  true  when  removing  the 
final(S)  component. 

The  program  of  interest.  We  will  use  the  notation  5*  to  repre¬ 
sent  the  program  that  we  are  analysing  (the  “top-level”  statement),  Lab*  to 
represent  the  labels  ( labels(S ))  appearing  in  5*,  Var*  to  represent  the  vari¬ 
ables  (FV(S*))  appearing  in  S*,  Blocks*  to  represent  the  elementary  blocks 
( blocks(S *))  occurring  in  5*,  and  AExp*  to  represent  the  set  of  non-trivial 
arithmetic  subexpressions  in  5*;  an  expression  is  trivial  if  it  is  a  single  vari¬ 
able  or  constant.  We  will  also  write  AExp(a)  and  AExp(i>)  to  refer  to  the 
set  of  non-trivial  arithmetic  subexpressions  of  a  given  arithmetic,  respectively 
boolean,  expression. 

To  simplify  the  presentation  of  the  analyses,  and  to  follow  the  traditions  of 
the  literature,  we  shall  frequently  assume  that  the  program  5*  has  isolated 
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entries;  this  means  that: 

W  €  Lab  :  (. e,init(S *))  $  flow(S*) 

This  is  the  case  whenever  5*  does  not  start  with  a  while-loop.  Similarly,  we 
shall  frequently  assume  that  the  program  5*  has  isolated  exits ;  this  means 
that: 

Wi  €  final(5*)  V/2  £  Lab  :  (tub)  £  fiow(S*) 

A  statement,  5,  is  /aftel  consistent  if  and  only  if: 

[B2Y  6  blocks(S)  implies  B\  = 

Clearly,  if  all  blocks  in  5  are  uniquely  labelled  (meaning  that  each  label  occurs 
only  once),  then  S  is  label  consistent.  When  S  is  label  consistent  the  clause 
“where  [B]1  e  blocks(S)”  is  unambiguous  in  defining  a  partial  function  from 
labels  to  elementary  blocks;  we  shall  then  say  that  t  labels  the  block  B.  We 
shall  exploit  this  when  defining  the  example  analyses  below. 

Example  2.3  The  power  program  of  Example  2.1  has  isolated  entries  but 
not  isolated  exits.  It  is  clearly  label  consistent  as  well  as  uniquely  labelled.  ■ 

2.1.1  Available  Expressions  Analysis 

The  Available  Expressions  Analysis'  will  determine: 

For  each  program  point,  which  expressions  must  have  already 
been  computed,  and  not  later  modified,  on  all  paths  to  the  pro¬ 
gram  point. 

This  information  can  be  used  to  avoid  the  re-computation  of  an  expression. 
For  clarity,  we  will  concentrate  on  arithmetic  expressions. 

Example  2.4  Consider  the  following  program: 

[x:=a+b]1-,  [y:=a*b]2; while  [y>a+b]3  do  ([a:=a+l]4;  [x:=a+b]5) 

It  should  be  clear  that  the  expression  a+b  is  available  every  time  execution 
reaches  the  test  (label  3)  in  the  loop;  as  a  consequence,  the  expression  need 
not  be  recomputed.  ■ 

The  analysis  is  defined  in  Table  2.1  and  explained  below.  An  expression  is 
killed  in  a  block  if  any  of  the  variables  used  in  the  expression  are  modified  in 
the  block;  we  use  the  function 


kfliAE  :  Blocks*  -»  P(AExp*) 
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kill  and  gen  functions 


kill ae ([x  :=  a]1) 
kiflAE([skipp) 
killAEdbY) 


{a'  e  AExp*  |  *  6  FV(a')} 
0 
0 


genAE([x  :=  a]') 
genAE  ([skip]') 
genAe([bY) 


=  {a'  e  AExp(a)  |  *  £  FV(a')} 

=  0 

=  AExp  (6) 


data  flow  equations:  AE 


kF  tp\  _  /  0  if  t  =  init(Sir) 

en(n/W  “  \  n{AE™«(0  1(^.0  €flow(5*)}  otherwise 

AEexit(^)  =  (AEentryW\idJ]AE(B<))UgenAE(BO 
where  B*  €  blocks(Si,) 


Table  2.1:  Available  Expressions  Analysis. 


to  produce  the  set  of  non-trivial  expressions  killed  in  the  block.  Test  and 
skip  blocks  do  not  kill  any  expressions  and  assignments  kill  any  expression 
that  uses  the  variable  that  appears  in  the  left  hand  side  of  the  assignment. 
Note  that  in  the  clause  for  [x:=aY  we  have  used  the  notation  a'  6  AExp* 
to  denote  the  fact  that  a'  is  a  non-trivial  arithmetic  expression  appearing  in 
the  program. 

A  generated  expression  is  an  expression  that  is  evaluated  in  the  block  and 
where  none  of  the  variables  used  in  the  expression  sire  later  modified  in  the 
block.  The  set  of  non-trivial  generated  expressions  is  produced  by  the  func¬ 
tion: 

genAE  :  Blocks*  ->  T*(AExp*) 

The  analysis  itself  is  now  defined  by  the  functions  AEentry  and  AEexit  that 
each  map  labels  to  sets  of  expressions: 

AE-entry j  AEei,'(  :  Lab*  ^  ,P(AExp*) 

For  a  label  consistent  program  5*  (with  isolated  entries)  the  functions  can 
be  defined  as  in  Table  2.1. 

The  analysis  is  a  forward  analysis  and,  as  we  shall  see,  we  are  interested 
in  the  largest  sets  satisfying  the  equation  for  AEentry  -  an  expression  will 
be  considered  available  if  no  path  kills  it.  No  expression  is  available  at  the 
start  of  the  program.  Subsequently,  the  expressions  that  are  available  at  the 
entry  to  a  block  are  any  expressions  that  are  available  at  all  of  the  exits 
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Figure  2.2:  A  schematic  flow  graph. 


from  blocks  that  flow  to  the  block;  if  there  are  no  such  blocks  the  formula 
evaluates  to  AExp*.  Given  a  set  of  expressions  that  are  available  at  the 
entry,  the  expressions  available  at  the  exit  of  the  block  are  computed  by 
removing  killed  expressions  and  adding  any  new  expression  generated  by  the 
block. 

To  see  why  we  require  the  largest  solution,  consider  Figure  2.2  which  shows 
the  flow  graph  for  a  program  in  a.  schematic  way.  Such  a  flow  graph  might 
correspond  to  the  following  program: 

[z:=x+y]*;  while  [true]*  do  [skip]* 


The  set  of  expressions  generated  by  the  first  assignment  is  {x+y};  the  other 
blocks  do  not  generate  expressions  and  no  block  kills  any  expressions.  The 
equations  for  AEeniry  and  AEexit  are  as  follows: 


AEgniry  (£) 

AE entry  {£') 
AE  entry  (?') 

AE  exit(i) 
AEexit(0 
AEeii4(r) 


0 

AEeiit(^)  n  AEexit(0 

AEeiit(f') 

AE  entry  (t)  U  {x+y} 

A  E  erltn/ (^) 

AEentrv(0 


After  some  simplification,  we  find  that: 

AEentry^')  =  {x+y}  D  AEen<ry(f') 

There  are  two  solutions  to  this  equation:  {x+y}  and  0.  Consideration  of 
the  example  and  the  definition  of  available  expressions  shows  that  the  most 
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informative  solution  is  {x+y}  -  the  expression  is  available  every  time  we  enter 
t' .  Thus  we  require  the  largest  solution  to  the  equations. 

Example  2.5  For  the  program 

[x^a+b]1;  [y:=a*b]2;  while  [y>a+b]3  do  ([a:=a+l]4;  [x:=a+b]5) 
of  Example  2.4,  Jci'IIae  and  genAE  are  defined  as  follows: 


l 

WUae  (0 

genAEW 

1 

0 

{a+b} 

2 

0 

{a*b} 

3 

0 

{a+b} 

4 

{a+b,  a*b,  a+l} 

0 

5 

0 

{a+b} 

We  get  the  following  equations: 


AEentry  (1) 

= 

0 

AEenfry(2) 

= 

AEeiit(l) 

AEentry  (3) 

= 

AEexit(2)  n  AEea;it(5) 

AEentry  (4) 

= 

AEeijt(3) 

AEgntry  (5) 

= 

AE  exit  (4) 

AEemt(l) 

= 

AEe„try(l)  U  {a+b} 

AEeIjt(2) 

= 

AEentry(2)U{a*b} 

A  E  exit  (3) 

= 

AEentry(3)  U  {a+b} 

AEei«(4) 

= 

A  E  entry  (4)\{a+b,  a*b,  a+l} 

AEeiit(5) 

= 

AEe„try(5)  U  {a+b} 

Using  an  analogue  of  the  Chaotic  Iteration  discussed  in  Chapter  1  (starting 
with  AExp*  rather  than  0)  we  can  compute  the  following  solution: 


i 

(^) 

AEexit(^) 

1 

0 

{a+b} 

2 

{a+b} 

{a+b,  a*b} 

3 

{a+b} 

{a+b} 

4 

{a+b} 

0 

5 

0 

{a+b} 

Note  that,  even  though  a  is  redefined  in  the  loop,  the  expression  a+b  is  re¬ 
evaluated  in  the  loop  and  so  it  is  always  available  on  entry  to  the  loop.  On 
the  other  hand,  a*b  is  available  on  the  first  entry  to  the  loop  but  is  killed 
before  the  next  iteration.  ■ 
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kill  and  gen  functions 


ldllRo([a:  :=  a}e) 

=  {(*,?)} 

U{(x,  £')  \Bl  is  an  assignment  to  x  in  5*} 

kiURD({skip}1) 

=  0 

killR0([bY) 

=  0 

genRD([a:  :=  a]') 

=  {(*.m 

genRoftskipj*) 

=  0 

genRD([6]*) 

=  0 

data  flow  equations:  RD= 

RD  (f)  -  I  {(*>?)  |XG  FV(5*)} 

entrvW  ~  1  U(R!WO  |  (£',£)  e  flow(S*)} 

if  £  =  intiiS*) 
otherwise 

RDeiif(*)  =  (RDentrvW\k/llRD(BO)UgenRD(BO 
where  Bl  €  blocks(S+) 

Table  2.2:  Reaching  Definitions  Analysis. 


2.1.2  Reaching  Definitions  Analysis 

As  mentioned  in  Chapter  1,  the  Reaching  Definitions  Analysis  should  more 
properly  be  called  reaching  assignments  but  we  will  use  the  traditional  name. 
This  analysis  is  analogous  to  the  previous  one  except  that  we  are  interested 
in: 


For  each  program  point,  which  assignments  may  have  been  made 
and  not  overwritten,  when  program  execution  reaches  this  point 
along  some  path. 

A  main  application  of  Reaching  Definitions  Analysis  is  in  the  construction 
of  direct  links  between  blocks  that  produce  values  and  blocks  that  use  them; 
we  shall  return  to  this  in  Subsection  2.1.5. 

Example  2.6  Consider  the  following  program: 

[x:=5]1;  [y:=l]2;while  [x>l]3  do  ([y:=x*y]4;  [x:=x-l]5) 

All  of  the  assignments  reach  the  entry  of  4  (the  assignments  labelled  1  and 
2  reach  there  on  the  first  iteration);  only  the  assignments  labelled  1,  4  and  5 
reach  the  entry  of  5.  ■ 

The  analysis  is  specified  in  Table  2.2.  The  function 

killRD  '■  Blocks*  -y  'PCVar*  x  Lab*) 
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produces  the  set  of  pairs  of  variables  and  labels  of  assignments  that  are 
destroyed  by  the  block.  An  assignment  is  destroyed  if  the  block  assigns  a 
new  value  to  the  variable,  i.e.  the  left  hand  side  of  the  assignment.  To  deal 
with  uninitialised  variables  we  shall,  as  in  Chapter  1,  use  the  special  label 

u*}n 

The  function 

genRD  :  Blocks*  -4  'P(Var*  x  Lab*) 

produces  the  set  of  pairs  of  variables  and  labels  of  assignments  generated  by 
the  block;  only  assignments  generate  definitions. 

The  analysis  itself  is  now  defined  by  the  pair  of  functions  RDentry  and  RD  exit 
mapping  labels  to  sets  of  pairs  of  variables  and  labels  (of  assignment  blocks): 

RDentry,  RDexit  :  Lab*  ->  P(Var*  x  Lab*) 


For  a  label  consistent  program  5*  (with  isolated  entries)  the  functions  are 
defined  as  in  Table  2.2. 

Similar  to  the  previous  example,  this  is  a  forward  analysis  but,  as  we  shall 
see,  we  are  interested  in  the  smallest  sets  satisfying  the  equation  for  RDentry. 
An  assignment  reaches  the  entry  of  a  block  if  it  reaches  the  exit  of  any  of 
the  blocks  which  precede  it;  if  there  are  none  the  formula  evaluates  to  0. 
The  computation  of  the  set  of  assignments  reaching  the  exit  of  a  block  is 
analogous  to  the  Available  Expressions  Analysis. 

We  motivate  the  requirement  for  the  smallest  solution  by  consideration  of 
the  program  [z:=x+y]*;  while  [true]*  do  [skip]*"  corresponding  to  Figure 
2.2  again.  The  equations  for  RDentry  and  RDc;cli  are  as  follows: 


RD  entry  (t) 
RDentry  (O 
RDe„try(0 

RDexit  W 
RDexit(0 

RDexit(n 


{(x,?),(y,?),(z,?)} 

RDexitWuRDeiit(0 

RDeiit(0 

(RDentryWU^MM)} 

RDentry  (O 

RDentn,(0 


Once  again,  we  concentrate  on  the  entry  of  the  block  labelled  RDentry{£')\ 
after  some  simplification  we  get 


RDentry  (?)  =  {(x,  ?),  (y,  ?),  (z,  £)}  U  RDe„try  (O 

but  this  equation  has  many  solutions:  we  can  take  RDentry  ((')  to  be  any 
superset  of  {(x,  ?),  (y,?),  (z,£)}.  However,  since  t'  does  not  generate  any  new 
definitions,  the  most  precise  solution  is  {(x,  ?),  (y,  ?),  (z,^)}  -  we  require  the 
smallest  solution  to  the  equations. 
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Sometimes,  when  the  Reaching  Definitions  Analysis  is  presented  in  the  liter¬ 
ature,  one  has  RDentrv(init(5*))  =  0  rather  than  RDentry(init(S*))  =  {(a:,?)  I 
x  €  FV(5*)}.  This  is  correct  only  for  programs  that  always  assign  variables 
before  their  first  use;  incorrect  optimisations  may  result  if  this  is  not  the  case. 
The  advantage  of  our  formulation,  as  will  emerge  from  Mini  Project  2.2,  is 
that  it  is  always  semantically  sound. 

Example  2.7  The  following  table  summarises  the  assignments  killed  and 
generated  by  each  of  the  blocks  in  the  program 


[x:=5]1;[y:=l]2;while  [x>l]3  do  ([y :=x*y]4;  [x:=x-l]5) 
of  Example  2.6: 


l 

killRD(t) 

genRD(i) 

1 

{(x,  ?),  (x,  1),  (x,  5)} 

{(*,!)} 

2 

{(y.?).(y.2),(y,4)} 

{(y,2)} 

3 

0 

0 

4 

{(y,?),(y,2),(y,4)} 

{(y,4)} 

5 

{(x,?),(x,l),(x,5)} 

{(x,5)} 

The  analysis  gives 

rise  to  the  following  equations: 

RDentry  (1) 

= 

{(*,?),  (r,?)} 

RDentrv(2) 

= 

RDeiit(l) 

RD  entry  (3) 

= 

RDex,t(2)  U  RDexit(5) 

RDentn/(4) 

= 

RDexit(3) 

RDentrt/(fi) 

= 

RDeIit(4) 

RDeiit(l) 

= 

(RDenfry(I)\{(x,  ?),  (x,  1),  (x,  5)})  U  {(x,  1)} 

RDeitt(2) 

= 

(RDmtrv(2)\{(y,  ?),  (y,  2),  (y, 4)})  U  {(y,  2)} 

RDexi<(3) 

= 

RD  entry  (3) 

RDeitt(4) 

= 

(RDe„tr»(4)\{(y,  ?),  (y,  2),  (y, 4)})  U  {(y,  4)} 

RDei»i(5) 

= 

(RDentry  (5)\{(X,  ?),  (x,  1),  (x,  5)})  U  {(x,  5)} 

Using  Chaotic  Iteration  we  may  compute  the  solution: 


l 

R  D  entry  (t) 

RDelitW 

1 

{(*,?),  (y ,?)} 

{(y,?),(x- 1)} 

2 

{(y,?)»(x,  l)} 

{(x,  l),  (y,  2)} 

3 

{(xi  i)>  (y>2),  (y,  4),  (x,  5)} 

{(x:i)>(y.2),(y>4),(x,5)} 

4 

{(x,l),(y,2),(y,4),(x,5)} 

{(x,l),(y,4),(x,5)} 

5 

{(x,l),(y,4),(x,5)} 

{(y,4),(x,5)} 

h 
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kill  and  gen  functions 


killVB([x  :=  a]*) 
lciiiVB([skip]f) 

kiUMlb}') 


{a‘  €  AExp*  |  x  6  FV(a')} 
0 
0 


genVB([x  :=  a]1)  =  AExp(a) 

genVB  ([skip]')  =  0 

graved^)  =  AExp(fe) 


VBeii^) 


VB  entry  (£) 


data  flow  equations:  VB 

f  0  if  l  £  final(S *) 

\  f]{VBen(n/(F)  |  (£',£)  £  flow^S,)}  otherwise 

(VB exit(£)\killvB(B<))  U  genVB(B') 
where  Be  €  blocks(S+) 


Table  2.3:  Very  Busy  Expressions  Analysis. 

2.1.3  Very  Busy  Expressions  Analysis 

An  expression  is  very  busy  at  the  exit  from  a  label  if,  no  matter  what  path 
is  taken  from  the  label,  the  expression  must  always  be  used  before  any  of  the 
variables  occurring  in  it  are  redefined.  The  aim  of  the  Very  Busy  Expressions 
Analysis  is  to  determine: 

For  each  program  point,  which  expressions  must  be  very  busy  at 
the  exit  from  the  point. 

A  possible  optimisation  based  on  this  information  is  to  evaluate  the  expres¬ 
sion  at  the  block  and  store  its  value  for  later  use;  this  optimisation  is  some¬ 
times  called  hoisting  the  expression. 

Example  2.8  Consider  the  program: 

if  [a>b]x  then  ([x:=b-a]2;  [y:=a-b]3)  else  ([y :  =b— a]4 ;  [x:=a-b]5) 

The  expressions  a-b  and  b-a  are  both  very  busy  at  the  start  of  the  condi¬ 
tional;  they  can  be  hoisted  to  the  start  of  the  conditional  resulting  in  a  space 
saving  in  the  size  of  the  code  generated  for  this  program.  ■ 

The  analysis  is  specified  in  Table  2.3.  We  have  already  defined  the  notion 
of  an  expression  being  killed  when  we  presented  the  Available  Expressions 


2.1  Intraprocedural  Analysis 


45 


Figure  2.3:  A  schematic  flow  graph  (in  reverse). 


Analysis;  we  use  an  equivalent  function  here: 

iciilvB  :  Blocks*  ->  P(AExp*) 

By  analogy  with  the  previous  analyses,  we  also  need  to  define  how  a  block 
generates  additional  very  busy  expressions.  For  this  we  use: 

geriVB  :  Blocks*  ->  73(AExp*) 

All  of  the  expressions  that  appear  in  a  block  are  very  busy  at  the  entry  to 
the  block  (unlike  what  was  the  case  for  Available  Expressions). 

The  analysis  itself  is  defined  by  the  pair  of  functions  VBentry  and  VBelit 
mapping  labels  to  sets  of  expressions: 

VBentry,  VBeIj4  :  Lab*  — >  ’P(AExp*) 

For  a  label  consistent  program  5*  (with  isolated  exits)  they  are  defined  as  in 
Table  2.3. 

The  analysis  is  a  backward  analysis  and,  as  we  shall  see,  we  are  interested  in 
the  largest  sets  satisfying  the  equation  for  VBeijt.  The  functions  propagate 
information  against  the  flow  of  the  program:  an  expression  is  very  busy  at 
the  exit  from  a  block  if  it  is  very  busy  at  the  entry  to  every  block  that  follows; 
if  there  are  none  the  formula  evaluates  to  AExp*.  However,  no  expressions 
are  very  busy  at  the  exit  from  any  final  block. 

To  motivate  the  fact  that  we  require  the  largest  set,  we  consider  the  situation 
where  we  have  a  flow  graph  as  shown  in  Figure  2.3;  this  flow  graph  might 
correspond  to  the  program: 

(while  [x>lj*  do  [skip]*  );[x:=x+l]f 

The  equations  for  this  program  are 


(} 


VBentry(£) 


VBeli4(f) 
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VE S'ntry{H) 

vb  entry(n 

VBeiit(£) 

VBeiit(f) 

VBeiit(f') 


VBex*(£') 

{x+l} 

VBentry(^')nVBen(rv(0 

VBentn,(f) 

0 


and,  for  the  exit  conditions  of  t,  we  calculate: 


VB  exit(e)  =  VBerit(£)n{x+l} 

Any  subset  of  {x+l}  is  a  solution  but  {x+l}  is  the  most  informative.  Hence 
we  want  the  largest  solution  to  the  equations. 


Example  2.9  To  analyse  the  program 

if  [a>b] 1  then  ([x:=b-a]2;  [y:=a-b]3)  else  ([y:=b-a]4;  [x:=a-b]5) 
of  Example  2.8,  we  calculate  the  following  killed  and  generated  sets: 


l 

kills,  bW 

Senvs  (£) 

n 

0 

0 

2 

0- 

{b-a} 

3 

0 

{a-b} 

4 

0 

{b-a} 

5 

0 

{a-b} 

We  get  the  following  equations: 


VBentry(l) 

= 

VBexit(l) 

VBen<ry(2) 

= 

VBexit(2)U{b-a} 

VBen{ry  (3) 

= 

{a-b} 

VBentry(4) 

= 

VBexif(4)U  {b-a} 

VB  entry  (5) 

= 

{a-b} 

VBexit(l) 

= 

VB  entry  (2)  n  VB  entry  (4) 

VBexit(2) 

= 

VBenfry  (3) 

VBexit(3) 

0 

VBexit(4) 

VB  erltrv  (5) 

VBexit(5) 

= 

0 

We  can  then  use  an  analogue  of  Chaotic  Iteration  (starting  with  AExp* 
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rather  than  0)  to  compute: 


t 

VBentry(e) 

1 

{a-b, b-a} 

{a-b, b-a} 

2 

{a-b,  b-a} 

{a-b} 

3 

{a-b} 

0 

4 

{a-b, b-a} 

{a-b} 

5 

{a-b} 

0 

2.1.4  Live  Variables  Analysis 

A  variable  is  live  at  the  exit  from  a  label  if  there  exists  a  path  from  the 
label  to  a  use  of  the  variable  that  does  not  re-define  the  variable.  The  Live 
Variables  Analysis  will  determine: 

For  each  program  point,  which  variables  may  be  live  at  the  exit 
from  the  point. 

This  analysis  might  be  used  as  the  basis  for  Dead  Code  Elimination.  If  the 
variable  is  not  live  at  the  exit  from  a  label  then,  if  the  elementary  block  is 
an  assignment  to  the  variable,  the  elementary  block  can  be  eliminated. 

Example  2.10  Consider  the  following  expression: 

[x :  =2] 1 ;  [y :=4]2;  [x:=i]3;  (if  [y>x]4  then  [z:=y]5  else  [z:=y*y]6);  [x:=z]7 

The  variable  x  is  not  live  at  the  exit  from  label  1;  the  first  assignment  of  the 
program  is  redundant.  Both  x  and  y  are  live  at  the  exit  from  label  3.  ■ 

The  analysis  is  defined  in  Table  2.4.  The  variable  that  appears  on  the  left 
hand  side  of  an  assignment  is  killed  by  the  assignment;  tests  and  skip  state¬ 
ments  do  not  kill  variables.  This  is  expressed  by  the  function: 

kiil|_v  :  Blocks*  -»  'P(Var*) 


The  function 


genLV  :  Blocks*  ->  P(Var*) 
produces  the  set  of  variables  that  appear  in  the  block. 

The  analysis  itself  is  defined  by  the  pair  of  functions  LVentry  and  LVei;t  map¬ 
ping  labels  to  sets  of  variables: 

IV exit,  LV entry  :  Lab*  -4  P(Var*) 
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kill  and  gen  functions 

killi\j([x  :=  a]*)  =  {x} 

kil/LV([skip]*)  =  0 

killLv([bY)  =  0 

genLV([x  :=  a]1)  =  FV(a) 
genLV([skip]*)  =  0 

genLV([6]*)  =  FV(b) 

data  flow  equations:  LV= 

LVeii£(f)  =  |  y{LVentry(f)  |  (£>,£)  e  flow"(S*)} 

if  £  e 
otherwise 

LV  entry  (£)  =  (LVeiu  (£)\killLV(B1))  U  genlw{Bl) 
where  Bl  €  blocks(Sit) 

Table  2.4:  Live  Variables  Analysis. 


For  a  label  consistent  program  5*  (with  isolated  exits)  they  can  be  defined 
as  in  Table  2.4.  The  equation  for  L\fexit(£)  includes  a  variable  in  the  set  of 
live  variables  (at  the  exit  from  £)  if  it  is  live  at  the  entry  to  any  of  the  blocks 
that  follow  £;  if  there  are  none  then  the  formula  evaluates  to  0. 

The  analysis  is  a  backward  analysis  and,  as  we  shall  see,  we  are  interested  in 
the  smallest  sets  satisfying  the  equation  for  LVeilt.  To  see  why  we  require 
the  smallest  set,  consider  once  again  the  program 

(while  [x>l]*  do  [skip]*  );[x:=x+l]* 


corresponding  to  the  flow  graph  in  Figure  2.3.  The  equations  for  the  program 
axe: 


LV  entry  (£) 
L V entry  (?) 
L V  entry  (0 

L Vexit(£) 
L V„«(0 
Lvextt(r) 


L Vei«e(f)  U  {x} 

LVeI*(£') 

W 

LVe„iry(f')  U  LV  entry  (t") 

LV  entry  {£) 

0 


Suppose  that  we  are  interested  in  LVea:;4(£);  after  some  calculation  we  get: 

LVeii£(f)  =  LVexit(f)  U  {x} 
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Any  superset  of  {x}  is  a  solution.  Optimisations  based  on  this  analysis  are 
based  on  “dead”  variables  -  the  smaller  the  set  of  live  variables,  the  more 
optimisations  are  possible.  Hence  we  shall  be  interested  in  the  smallest  solu¬ 
tion  {x}  to  the  equations.  Correctness  of  the  analysis  will  be  established  in 
Section  2.2. 

Example  2.11  Returning  to  the  program 
[x:=2]1;  [y:=4]2;  [x:=l]3;  (if  [y>x]4  then  [z:=y]5  else  [z:=y*y]6);  [x:=z]7 
of  Example  2.10,  we  can  compute  killiv  and  genLV  as: 


t 

kill LV(0 

genLv{t) 

1 

« 

0 

2 

{y} 

0 

3 

{*} 

0 

4 

0 

{*,y} 

5 

{z} 

{y} 

6 

M 

{y} 

7 

M 

{z} 

We  get  the  following  equations: 


LVentry(l) 

= 

LVe.it(l)\{x} 

LVentry(2) 

= 

- -LVe.it  (2)\{y> 

IV entry  (3) 

= 

LVe.it  (3)\{x} 

LV entrJ/  (4) 

= 

LVe.it  (4)  U  {x,  y} 

LVentry(5) 

= 

(LVe.it (5)\{z})  U  {y} 

LV entry  (0) 

= 

(LVe.it  (6)\{z»  U  {y} 

LVe„try(7) 

= 

{z} 

LVexit(l) 

= 

LV  entry  (2) 

LVe.it  (2) 

= 

LV  entry  (3) 

LVeltt(3) 

= 

LV  entry  (4) 

LVe.it  (4) 

= 

LVe„try(5)  U  LVe„try(6) 

LVe.it  (5) 

= 

LV  entry  (7) 

LVe.it(6) 

= 

LV  entry  (7) 

LVe.it  (7) 

= 

0 

We  can  then  use  Chaotic  Iteration  to  compute  the  solution: 
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£ 

LVentrv(^) 

LV  exit(£) 

1 

0 

0 

2 

0 

{y} 

3 

{y} 

{*,y} 

4 

{x,y} 

{y} 

5 

{y} 

{z} 

6 

{y} 

{z} 

7 

{z} 

0 

Note  that  we  have  assumed  that  all  variables  are  dead  at  the  end  of  the 
program.  Some  authors  assume  that  the  variables  of  interest  are  output  at 
the  end  of  the  program;  in  that  case  LVextt(7)  should  be  {x,  y,  z}  which  means 
that  LVe„trv(7),  LVei,t(5)  and  LVeiit(6)  should  all  be  {y,z}.  ■ 

2.1.5  Derived  Data  Flow  Information 

It  is  often  convenient  to  directly  link  labels  of  statements  that  produce  values 
to  the  labels  of  statements  that  use  them.  Links  that,  for  each  use  of  a  vari¬ 
able,  associate  all  assignments  that  reach  that  use  are  called  Use-Definition 
chains  or  ad-chains.  Links  that,  for  each  assignment,  associate  all  uses  are 
called  Definition- Use  chains  or  da-chains  . 

In  order  to  make  these  definition?  more  precise,  we  will  use  the  notion  of  a 
definition  clear  path  with  respect  to  some  variable.  The  idea  is  that  £\ ,■■■,£„ 
is  a  definition  clear  path  for  x  if  none  of  the  blocks  labelled  £\ ,  ■  •  • ,  £n  assigns 
a  value  to  x  and  if  £n  uses  x.  Formally,  for  a  label  consistent  program  5*  we 
define  the  predicate  dear  : 

cle ar(x,£,£')  =  3£i,  •  ■•,£„: 

(4  —  £)  A  (£„  =  £')  A  (n  >  0)  A 

(Vi  e  {1, 1}  :  (£i,£i+ i)  e  flow(S*))  A 

(Vi  S  {1,  —  1}  :  ~'def{x,£i))  A  use(x,£n) 

Here  the  predicate  use  checks  whether  the  variable  is  used  in  a  block 

use(x,£)  =  (3  B  :  [B]1  e  MocIcs(S*)  Axe  genLV([5]*)) 

and  the  predicate  def  checks  whether  the  variable  is  assigned  in  a  block: 

def{x,£)  =  (35  :  [B]e  €  blocks(Sir)  Axe  killlv({B]e)) 

Armed  with  these  definitions,  we  can  define  the  functions 


ud,  du  :  Var*  x  Lab*  — >  V  (Lab*) 
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as  follows: 


ud(x,£') 


=  {£  |  def(x,  t)  A  3£"  :  (£,  £")  €  flow(S.)  A  clear(x,  £" ,  £')} 

U  {?  |  cleax(x,init(Sir),£')} 


du(x,£ ) 


{£'  |  def{x,£)  A  31"  :  {£,£")  e  flow(S*)  A  c/ear(x,f",f')} 
if  ? 

{f'  |  clear(x,  init(S *),£')} 
if  f  =  ? 


So  ud(x,£')  will  return  the  labels  where  an  occurrence  of  a:  at  might  have 
obtained  its  value;  this  may  be  at  a  label  l  in  5*  or  x  may  be  uninitialised  as 
indicated  by  the  occurrence  of  And  du(x,£)  will  return  the  labels  where 
the  value  assigned  to  x  at  C  might  be  used;  again  we  distinguish  between 
the  case  where  x  gets  its  value  within  the  program  and  the  case  where  it  is 
uninitialised.  It  turns  out  that: 


du(x,£)  =  {£'  |  £  €  ud(x,£')} 

Before  showing  how  ud-  and  du-chains  can  be  used,  we  illustrate  the  functions 
by  a  simple  example. 

Example  2.12  Consider  the  program: 

[x :  =0] 1 ;  [x:=3]2;  (if  [z=x]3  then{z:=0]4  else  [z:=x]5);  [y:=x]6;  [x:=y+z]7 


Then  we  get: 


ud(x,£) 

X 

y 

z 

du(x,£) 

X 

y 

z 

1 

0 

0 

0 

1 

0 

0 

0 

2 

0 

0 

0 

2 

{3,5,6} 

0 

0 

3 

{2} 

0 

{?} 

3 

0 

0 

0 

4 

0 

0 

0 

4 

0 

0 

{7} 

5 

{2} 

0 

0 

5 

0 

0 

{7} 

6 

{2} 

0 

0 

6 

0 

{7} 

0 

7 

0 

{6} 

{4,5} 

7 

0 

0 

0 

? 

0 

0 

{3} 

The  table  for  ud  shows  that  the  occurrence  of  x  in  block  3  will  get  its  value 
in  block  2  and  the  table  for  du  shows  that  the  value  assigned  to  x  in  block  2 
may  be  used  in  block  3,  5  and  6.  ■ 


One  application  of  ud-  and  da-chains  is  for  Dead  Code  Elimination-,  for  the 
program  of  Example  2.12  we  may  e.g.  remove  the  block  labelled  1  because 
there  will  be  no  use  of  the  value  assigned  to  x  before  it  is  reassigned  in  the 
next  block.  Another  application  is  in  Code  Motion;  in  the  example  program 
the  block  labelled  6  can  be  moved  to  just  in  front  of  the  conditional  because 
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it  only  uses  variables  assigned  in  earlier  blocks  and  the  conditional  does  not 
use  the  variable  assigned  in  block  6. 

The  definitions  of  ud-  and  du-chains  do  not  give  any  hints  as  to  how  to 
compute  the  chains  -  the  definitions  are  not  constructive.  It  is  possible  to 
give  constructive  definitions  which  re-use  some  of  the  functions  that  we  have 
defined  in  the  earlier  examples.  In  order  to  define  ud-chains  we  can  use 
Reentry !  which  records  the  assignments  reaching  a  block  and  define 

UD  :  Var*  x  Lab*  ->  P(Lab*) 


by: 

UDfx  £)  =  /  ^  ^  ^  Reentry (f)}  if  %  €  genm(Be) 

'  ’  '  \  0  otherwise 

Similarly,  we  can  define  a  function  DU  :  Var*  x  Lab*  — >  T*(Lab*)  for  du- 
chains  based  on  the  functions  we  have  seen  previously.  We  shall  leave  this  to 
Mini  Project  2.1  where  we  also  consider  the  formal  relationship  between  the 
UD  and  DU  functions  and  the  functions  ud  and  du. 


2.2  Theoretical  Properties 

In  this  section  we  will  show  that  the  Live  Variables  Analysis  of  Subsection 
2.1.4  is  indeed  correct;  the  correctness  of  the  Reaching  Definitions  Analysis  is 
the  topic  of  Mini  Project  2.2.  We  shall  begin  by  presenting  a  formal  semantics 
for  While. 

The  material  of  this  section  may  be  skimmed  through  on  a  first  reading; 
however,  it  is  frequently  when  conducting  the  correctness  proof  that  the  final 
and  subtle  errors  in  the  analysis  are  found  and  corrected!  In  other  words, 
proving  the  semantic  correctness  of  the  analysis  should  not  be  considered  a 
dispensable  development  that  is  merely  of  interest  for  theoreticians. 

2.2.1  Structural  Operational  Semantics 

We  choose  to  use  a  (so-called  small  step)  Structural  Operational  Semantics 
because  it  allows  us  to  reason  about  intermediate  stages  in  a  program  execu¬ 
tion  and  it  also  allows  us  to  deal  with  non-terminating  programs. 

Configurations  and  transitions.  First  define  a  state  as  a  mapping 
from  variables  to  integers: 

cr  €  State  =  Var  — >  Z 

A  configuration  of  the  semantics  is  either  a  pair  consisting  of  a  statement 
and  a  state  or  it  is  a  state;  a  terminal  configuration  is  a  configuration  that 
simply  is  a  state.  The  transitions  of  the  semantics  are  of  the  form 
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A  :  AExp  -4  (State  -4  Z) 

A[x]a  =  a(x) 

A[n](r  =  A/|n] 

A[ai  opa  a2]a  =  A[a{\a  opa  A[a2 \a 

B  :  BExp  -4  (State  -4  T) 

Sfnot  b]cr  =  -i. B[b\cr 
B[bi  opb  hja  =  B[bi]cr  opt  B[b2]a 

B{a\  opr  a2]a  =  A{ai]a  opr  A[a2]a 

Table  2.5:  Semantics  of  expressions  in  While. 

(S,cr)  -4  a'  and  (S,a)  -4  {S'  ,a') 

and  express  how  the  configuration  is  changed  by  one  step  of  computation. 
So  in  the  configuration  (S,  a)  one  of  two  things  may  happen: 

•  the  execution  terminates  after  one  step  and  we  record  that  by  giving 
the  resulting  state  a',  or 

•  the  execution  does  not  terminate  after  one  step  and  we  record  that  by 
a  new  configuration  (S',  a')  where  S'  is  the  rest  of  the  program  and  a' 
is  the  updated  state. 

To  deal  with  arithmetic  and  boolean  expressions  we  require  the  semantic 
functions 

A  :  AExp  -4  (State  -4  Z) 

B  :  BExp  -4  (State  —4  T) 

whose  definition  are  given  in  Table  2.5.  Here  we  assume  that  opa,  op6  and 
opr  are  the  semantic  counterparts  of  the  corresponding  syntax.  We  have 
also  assumed  the  existence  of  bf  :  Num  — )■  Z  which  defines  the  semantics 
of  numerals.  For  simplicity  we  have  assumed  that  no  errors  can  occur;  this 
means  that  e.g.  division  by  0  will  have  to  produce  an  integer.  One  can  modify 
the  definition  so  as  to  allow  errors  but  this  will  complicate  the  correctness 
proof  to  be  performed  below.  Note  that  the  value  of  an  expression  is  only 
affected  by  the  variables  appearing  in  it,  that  is: 

if  Vx  £  FV(a)  :  oi(x)  =  a2(x)  then  Afojcr!  =  A[ajcr2 
if  Vx  £  FV(b )  :  cti(x)  =  er2(x)  then  B{b]c 7\  =  B\b\a2 

These  results  can  easily  be  proved  by  structural  induction  on  expressions 
(or  by  mathematical  induction  on  their  size);  see  Appendix  B  for  a  brief 
introduction  to  these  proof  principles. 
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[ass] 

([x  :=  a]*,  a)  ->  cr[x  A[a]a] 

[s£ip] 

{[skip]*,  cr)  ->  cr 

[*e?i] 

(Sua)  ^  (S'lta') 

(Si;Si,a)  ->  (S^Si'CT1) 

[seq2] 

(Si, a)  -Kcr' 

(Si; Si, a)  ->  (Si, a') 

Wi) 

(if  [6]*  then  Si  else  Si, a)  -*  (5i,cr) 

if  B[b}a  =  true 

[*/a] 

(if  [6]*  then  Si  else  Si, a)  -»•  (Si, a) 

if  B{b\o  =  false 

Mi] 

(while  [6]*  do  5, cr)  ->  {(5;  while  [6]*  do  S),a) 

if  B[b\o  =  true 

[wh2] 

(while  [6]*  do  S,a)  -4  cr 

if  B\b\a  =  false 

Table  2.6:  The  Structural  Operational  Semantics  of  Whilz;. 


The  detailed  definition  of  the  semantics  of  the  statements  may  be  found  in 
Table  2.6;  it  is  explained  below. 

The  clause  [ass]  specifies  that  the  assignment  x  :=  a  is  executed  in  one  step; 
here  we  write  a[x  i->  A[a]cr]  for  the  state  that  is  as  cr  except  that  x  is  mapped 
to  A{a]a,  i.e.  the  value  that  a  will  evaluate  to  in  the  state  a.  Formally: 

M*  «  A[a}a])y  =  {  ^ 

The  semantics  of  sequencing  is  given  by  the  two  rules  [seq,  ]  and  [seq2\  and 
the  idea  is  as  follows.  The  first  step  of  executing  Si;  Si  is  the  first  step  of 
executing  Si .  It  may  be  that  only  one  step  is  needed  for  Si  to  terminate  and 
then  the  rule  [ seq2 ]  applies  and  says  that  the  new  configuration  is  (52, cr') 
reflecting  that  we  are  ready  to  start  executing  Si  in  the  next  step.  Alter¬ 
natively,  S\  may  not  terminate  in  just  one  step  but  gives  rise  to  some  other 
configuration  (5[,cr');  then  the  rule  [segj  applies  and  it  expresses  that  the 
rest  of  Si  and  all  of  Si  still  have  to  be  executed:  the  next  configuration  is 
(S[]  Si,a'). 

The  semantics  of  the  conditional  is  given  by  the  two  axioms  [i/j]  and  [if2]  ex¬ 
pressing  that  the  first  step  of  computation  will  select  the  appropriate  branch 
based  on  the  current  value  of  the  boolean  expression. 

Finally,  the  semantics  of  the  while-construct  is  given  by  the  two  axioms  [w/ii] 
and  [whi];  the  first  axiom  expresses  that  if  the  boolean  expressions  evaluates 
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to  true  then  the  first  step  is  to  unroll  the  loop  and  the  second  axiom  expresses 
that  the  execution  terminates  if  the  boolean  expression  evaluates  to  false. 

Derivation  sequences.  A  derivation  sequence  for  a  statement  Si  and 
a  state  <ti  can  take  one  of  two  forms: 

•  It  is  a  finite  sequence  of  configurations  (Si ,  cri),  •  •  • ,  (Sn,  <rn),  on+\  sat¬ 
isfying  { Si,<?i )  ->  (Sj+i,<Tj+i)  fori  =  1,  •••,«  — 1  and  (S„,ct„)  ->  crn+1; 
this  corresponds  to  a  terminating  computation. 

•  It  is  an  infinite  sequence  of  configurations  (Si,  a  i),  •  •  • ,  (Si,  <7i),  •  •  •  satis¬ 
fying  (S{, fTj)  -¥  (Si+i,cri+i)  for  all  *  >  1;  this  corresponds  to  a  looping 
computation. 


Example  2.13  We  illustrate  the  semantics  by  showing  an  execution  of 
the  factorial  program  of  Example  1.1.  In  the  following  we  assume  that  the 
state  ffnx„ynM  maps  x  to  nx,  y  to  ny  and  z  to  n2.  We  then  get  the  following 
finite  derivation  sequence: 

<[y i”*]1;  [z:=l]2; while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y  :=0]6,a3oo> 

->  ([z:=l]2;wMle  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y:=0]V330> 

->  (while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y :  =0]6,  cr33X> 

->  ([z:=z*y]4;[y:=y-l]5;  "" 

while  [y> l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y:=0]6,cr33i) 

->  ([y:=y-l]5;while  [y>l]3  do  ([z:=z*y]4;  [y :=y-l]5);  [y :=0]6,a333) 

(while  [y>l]3  do  ([z:=z*y]4; [y:=y-l]5); [y:=0]6,c7323> 

->  ([z:=z*y]4;[y:=y-i]5; 

while  [y>l]3  do  ([z:=z*y]4;  [y :  =y-l]5);  [y :  =0]6, cr323) 

->  ([y:=y-l]5;while  [y>l]3  do  ([z:=z*y]4;  [y:=y-l]5);  [y:=0]6,ff326) 

-¥  (while  [y>l]3  do  ([z:=z*y]4;  [y  :=y-l]5);  [y:=0]6,  <73i6) 

->  ([y:=0]6,<T3i6) 

CT306 

Note  that  labels  have  no  impact  on  the  semantics:  they  are  merely  carried 
along  and  never  inspected.  ■ 

Properties  of  the  semantics.  We  shall  first  establish  a  number  of 
properties  of  the  operations  on  programs  and  labels  that  we  have  used  in 
the  formulation  of  the  analyses.  In  the  course  of  the  computation  the  set  of 
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flows,  the  set  of  final  labels  and  the  set  of  elementary  blocks  of  the  statements 
of  the  configurations  will  be  modified;  Lemma  2.14  shows  that  the  sets  will 
decrease: 

Lemma  2.14 

(i)  If  (S,  a)  -4  o'  then  final(S)  =  {init(S)}. 

(ii)  If  (S,cr)  -4  (S', a')  then  Bnal(S)  D  final(S'). 

(iii)  If  (S,  o)  -4  ( S',<r ')  then  flow(S)  3  flow(S'). 

(iv)  If  ( S,o )  -4  (S',  a')  then  blocks(S)  D  blocks(S')  and  if  S  is  label  con¬ 
sistent  then  so  is  5'.  ■ 

Proof  The  proof  of  (i)  is  by  induction  on  the  shape  of  the  inference  tree  used  to 
establish  ( S,a )  -4  o' \  we  refer  to  Appendix  B  for  a  brief  introduction  to  the  proof 
principle.  Consulting  Table  2.6  we  see  that  there  are  three  non-vacuous  cases: 

The  case  [ass].  Then  ([i  :=  a]*,  a)  — >  o[x  >4  A[a]o]  and  we  get: 

Gnal([x  :=  a]*)  =  {f}  =  {init([a:  :=  a]*)} 

The  case  [sfcip].  Then  ([skip]*,  <r)  -4  o  and  we  get: 

fina/([skip]<)  =  {f}  =  {init([skip]<)} 

The  case  [U//12]-  Then  (while  [6]^  do  S;o)  — >  o  because  B\b\o  =  false  and  we  get: 

fina/(while  [b]*  do  S)  =  {£}  =  { ini  t(  while  [b]*  do  5)} 

This  completes  the  proof  of  (i). 

The  proof  of  (ii)  is  by  induction  on  the  shape  of  the  inference  tree  used  to  establish 
(S,o)  -4  (S',  o').  There  are  five  non-vacuous  cases: 

The  case  [se^J.  Then  (Si;  S2,  o)  -4  (S(\  S2,  o')  because  (Si,  a)  -4  (S],  cr'}  and  we 
get: 

Gnal(Sv,  S2)  =  fina i(S2)  =  finai(S'l;  S2) 

The  case  [ seq2 ].  Then  (Si;S2,<r)  -4  (S2,o-')  because  (Si,cr)  -4  o'  and  we  get: 

fina/(Si;  S2)  =  fina i(S2) 

The  case  [t/J.  Then  (if  [6]*  then  Si  else  S2, o)  -4  (Si,cr)  because  B[b)o  =  true 
and  we  get: 

final(if  [b]*  then  Si  else  S2)  =  final(Si)  U  fina i(S2)  3  finai(Si) 

The  case  [i/2]  is  similar  to  the  previous  case. 

The  case  [w/ii].  Then  (while  [6]*  do  S,o)  -4  ((S;  while  [b]*  do  S),o)  because  £S[6]<t 
=  true  and  we  get: 

fina/(S;  while  [6]*  do  S)  =  finai(while  [b]*  do  S) 


2.2  Theoretical  Properties 


5 / 

This  completes  the  proof  of  (ii). 

The  proof  of  (iii)  is  by  induction  on  the  shape  of  the  inference  tree  used  to  establish 
— *•  {S', a').  There  are  five  non-vacuous  cases: 

The  case  [segj.  Then  (Si;  S2,  a)  — >  (S'1;S2,<r')  because  (Si, <7)  -»•  ( S[,cr ')  and  we 
get 

flow(Si;S2)  =  flow(Si)  U  fiow(S2)  U  {(£,init(S2))  |  £  €  finai(Si)} 

3  6ow(S[)  U  flow(S2)  U  {(£,init(S2))  1 1  €  finai(Si)} 

3  Bow(S[)  U  Bow(S2)  U  {(£,init(S2))  |£€fina/(S'1)} 

=  Bow(S[;  S2) 

where  we  have  used  the  induction  hypothesis  and  (ii). 

The  case  [seq2\.  Then  {Si;Si,a)  —y  (S2, cr')  because  (Si, <7)  — >  <7'  and  we  get: 

fiow{Si;  S2)  =  flow(Si)  U  Bow{Si)  U  {(f,  init(S2))  |  f  €  finai(Si)} 

3  8ow(S2) 

The  case  [t/j].  Then  (if  [fe]^  then  Si  else  S2, cr)  — >  (Si, <7)  because  B[b]cr  =  true 
and  we  get: 

flow( if  [6]'’  then  Si  else  S2)  =  Bow(Si)  U  Bow(S2) 

U  {(£,  init(Si)),  {£,  init(S2))} 
r.  3  Bow(Si) 

The  case  [i/2]  is  similar  to  the  previous  case. 

The  case  [1 ohi].  Then  (while  [6]'  do  S,  a)  -y  (S;  while  [&]*  do  S,  a)  because  B\b\a 
=  true  and  we  get: 

3ow(S;  while  [6]*  do  S)  =  Bow(S)  U  flow( while  [6]<  do  S) 

U  {(/,£)  |  d  €  finai(S)} 

=  flow(S)  U  flow(S)  U  {{£,  init(S))} 

U  {(€',  £)  I  d  €  Bnal(S)}  U  {(d ,£)  |  ^  €  final(S)} 

=  Bow(S)  U  {(£,  init(S))}  U  {{£’,£)  \  £'  <E  final(S)} 

=  flow( while  [fc]^  do  S) 

This  completes  the  proof  of  (iii). 

The  proof  of  (iv)  is  similar  to  that  of  (iii)  and  we  omit  the  details.  ■ 

2.2.2  Correctness  of  Live  Variables  Analysis 

Preservation  of  solutions.  Subsection  2.1.4  shows  how  to  define  an 
equation  system  for  a  label  consistent  program  S*  (with  isolated  exits);  we  will 
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refer  to  this  system  as  LV  (5*).  The  construction  of  LV  (5*)  can  be  modified 
to  give  a  constraint  system  LV-(5*)  of  the  form  studied  in  Subsection  1.3.2: 


IV  m  -j  /  0  aeeGnal(S*) 

“•*w  -  1  U{LVe„!rv(f )  |  (t ,/)  e  flow*(S*)}  Otherwise 

LVen(ry(f)  D  (l\/extt(£)\kniLV(Be))UgenLV(Bl) 
where  Be  £  blocks(Sir) 

We  make  this  definition  because  in  the  correctness  proof  we  will  want  to  use 
the  same  solution  for  all  statements  derived  from  5*;  this  will  be  possible  for 
LV-(S*)  but  not  for  LV=(S*). 

Now  consider  a  collection  live  of  functions: 


live  entry,  live  exit  :  Lab*  ->  T^Var*) 

We  say  that  live  solves  LV=(S),  and  write 

live  |=  LV=(S) 

if  the  functions  satisfy  the  equations;  similarly  we  write 

live  j=  LV-  (S) 

if  live  solves  LV -(£*).  The  following  result  shows  that  any  solution  of  the 
equation  system  is  also  a  solution  of  the  constraint  system  and  that  the  least 
solutions  of  the  two  systems  coincide. 

Lemma  2.15  Consider  a  label  consistent  program  5*.  If  live  |=  LV=(5*) 
then  live  |=  LV-(S*).  The  least  solution  of  LV=(S*)  coincides  with  the  least 
solution  of  LV- (5*).  ■ 

Proof  If  live  |=  LV=(S.)  then  clearly  live  |=  LV-(S'*)  because  “D”  includes  the 
case  of  “=”. 

Next  let  us  prove  that  LV-(S.)  and  LV=(S»)  have  the  same  least  solution.  We 
gave  a  constructive  proof  of  a  related  result  in  Chapter  1  (under  some  assumptions 
about  finiteness)  so  let  us  here  give  a  more  abstract  proof  using  more  advanced 
fixed  point  theory  (as  covered  in  Appendix  A).  In  the  manner  of  Chapter  1  we 
construct  a  function  jFLv  such  that: 

live  j=  LV-(S)  iff  live  □  F^j(live) 

live  f=  LV=(S)  iff  live  =  F^j(live) 

Using  Tarski’s  Fixed  Point  Theorem  (Proposition  A. 10)  we  now  have  that  F{y  has 
a  least  fixed  point  lfp(F^)  such  that 

lfp(Fw)  =  n{«ve  |  live  □  FVv (five) }  =  f]{h’ve  |  live  =  FLv(!ive)} 


f 
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(S,*i)  (S', a  1) 


(7 


/// 

1 


|=  LV- 


f=  LV- 


f=  LV- 


iive 


live 


live 


Figure  2.4:  Preservation  of  analysis  result. 


and  since  lfp(FLv)  =  F^(lfp(F^))  as  well  as  lfp(F^)  □  F§/(lfp(F^,))  this  proves 
the  result.  ■ 

The  next  result  shows  that  if  we  have  a  solution  to  the  constraint  system 
corresponding  to  some  statement  Si  then  it  will  also  be  a  solution  to  the 
constraint  system  obtained  from  a  sub-statement  S2;  this  result  will  be  es¬ 
sential  in  the  proof  of  the  correctness  result. 

Lemma  2.16  If  live  |=  LV-(5i)  (with  Si  being  label  consistent)  and 
flow(Si)  D  flow(S2 )  and  blocks(Si)  D  blocks(S 2)  then  live  j=  LV-(52)  (with 
S2  being  label  consistent).  ■ 

Proof  If  Si  is  label  consistent  and  'Blocks(Si)  3  blocks(S2)  then  also  S2  is  label 
consistent.  If  live  f=  LV- (Si)  then  live  also  satisfies  each  constraint  in  LV- (S2)  and 
hence  live  \=  LV-(S2).  ■ 

We  now  have  the  following  corollary  expressing  that  the  solution  to  the  con¬ 
straints  of  LV-  is  preserved  during  computation;  this  is  illustrated  in  Figure 
2.4  for  finite  computations. 

Corollary  2.17  If  live  f=  LV-(5)  (for  S  being  label  consistent)  and  if 
( 5,er )  (S',  a')  then  also  live  \=  LV-(S').  ■ 

Proof  Follows  from  Lemma  2.14  and  2.16.  ■ 

We  also  have  an  easy  result  relating  entry  and  exit  components  of  a  solution. 

Lemma  2.18  If  live  )=  LV-(S)  (with  S  being  label  consistent)  then  for 
all  (£,£')  6  flow(S)  we  have  liveexit(£)  2  hveenen/(f).  ■ 

Proof  The  result  follows  immediately  from  the  construction  of  LV-(S).  ■ 

Correctness  relation.  Intuitively,  the  correctness  result  for  the  Live 
Variables  Analysis  should  express  that  the  sets  of  live  variables  computed  by 
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jyn 


J*(t) 


>  (S",<r£>  < 

V"  =  N(init(S"))  letinal(S) 


(S,0i) 


(S',*  i) 


(S,<r2>  ->  (S', o^) 

V  =  N{ioit(S))  V'  =  N{imt(S')) 


Figure  2.5:  The  correctness  result  for  live. 


the  analysis  are  correct  throughout  the  computation.  Only  the  values  of  the 
live  variables  are  of  interest  for  the  computation:  if  a  variable  is  not  live  then 
its  value  in  the  state  is  irrelevant  -  its  value  cannot  affect  the  interesting 
parts  of  the  result  of  the  computation.  Assume  now  that  V  is  a  set  of  live 
variables  and  define  the  correctness  relation: 

0\  02  iff  Vr  e  V  :  Oi(x)  =  02(x) 

The  relation  expresses  that  for  all  practical  purposes  the  two  states  o\  and 
02  are  equal:  only  the  values  of  the  live  variables  matters  and  here  the  two 
states  are  equal. 

Example  2.19  Consider  the  statement  (x:=y+z]/  and  let  Vi  =  {y,  z}  and 
V2  =  {x}.  Then  Oi  ~Vi  02  means  0\  (y)  =  er2 (y)  A  <7i(z)  =  o2(z)  and 
o\  ~v2  02  means  01  (x)  =  ff2(x). 

Next  suppose  that  ([x:=y+z]*,eri)  — >•  o[  and  ([x:=y+z],,cr2)  ->  o'2.  Clearly 
o  1  ~Vi  02  ensures  that  o[  o'2.  So  if  V2  is  the  set  of  variables  live  after 
[x:=y+z]*  then  Vi  is  the  set  of  variables  live  before  [x:=y+z]T  ■ 

The  correctness  result  will  express  that  the  relation  is  an  invariant  under 
the  computation.  This  is  illustrated  in  Figure  2.5  for  finite  computations  and 
it  is  formally  expressed  by  Corollary  2.22  below;  to  improve  the  legibility  of 
formulae  we  write: 


1V(£)  =  liveentry(£) 

X(i)  =  liveexit(l) 

Since  the  live  variables  at  the  exit  from  a  label  are  defined  to  be  (a  superset 
of)  the  union  of  the  live  variables  at  the  entries  of  all  of  it  successor  labels, 
we  have  the  following  result. 
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Lemma  2.20  Assume  live  (=  LV-(5)  with  5  being  label  consistent.  Then 
ci  ~x(o  a2  implies  ~n(c)  °2  for  all  (£,£')  6  Qow(S).  m 

Proof  Follows  directly  from  Lemma  2.18  and  the  definition  of  ~v-  * 

Correctness  result.  We  are  now  ready  for  the  main  result.  It  states 
how  semantically  correct  liveness  information  is  preserved  under  each  step  of 
the  execution:  (i)  in  the  case  where  we  do  not  immediately  terminate  and 
(ii)  in  the  case  where  we  do  immediately  terminate. 


Theorem  2.21 

If  live  |=  LV-(S)  (with  5  being  label  consistent)  then: 

(i)  if  (S, <Ti)  -4  (S', a[)  and  o\  ~jv(in/t(S))  ai  then  there  exists 
a2  such  that  (5,(72)  ->•  (S' ,o2)  and  a[  ~N(mit(S'))  and 

(ii)  if  (5,(7i)  -4  a[  and  crj  ~N(init(S))  ai  then  there  exists  a2 
such  that  (S,<j2)  ->  a2  and  a(  ~X(init(S)) 


Proof  The  proof  is  by  induction  on  the  shape  of  the  inference  tree  used  to  establish 
(S,  <ri)  -4  (S'  ,a()  and  (S,  cri)  -4  a(,  respectively. 

The  case  [ass].  Then  ([a;  :=  a]*,  cri)  -4  <7i[x  t->  A[a]ai]  and  from  the  specification 
of  the  constraint  system  we  have 

N(i)  =  livecntry(£)  =  (liveexit(e)\{x})  U  FV(a)  =  (X(£)\{*})  U  FV(a) 


and  thus 


~n(<)  C2  implies  A[a]<7i  =  A\a\i 72 


because  the  value  of  a  is  only  affected  by  the  variables  occurring  in  it.  Therefore, 
taking 

a 2  =  <72(1  4  A[a\a2] 

we  have  that  cr'i(x)  =  a2(x)  and  thus  a[  ~x(<)  a2  as  required. 

The  case  [skip].  Then  ([skip]*,  o\)  -4  cri  and  from  the  specification  of  the  constraint 
system 


N(t)  =  livecntry  (f )  =  (Uvecxit  (£  )\0)  U  0  =  live  exit  (£)  =  X(i) 


and  we  take  a'2  to  be  (72. 

The  case  [se^].  Then  (Si;S2,0i)  -4-  (S( ;  S2 , a( )  because  (S\,a\)  -4  (S[,cr'i).  By 
construction  we  have  Sow(Si;  S2)  2  Row(Si)  and  also  blocks(Si;  S2)  2  blocks(Si). 
Thus  by  Lemma  2.16,  live  is  a  solution  to  LV-(S  1)  and  thus  by  the  induction 
hypothesis  there  exists  a2  such  that 

(Si,<72)  -4  (S'i,a2)  and  a\  ~AT(init(Sj)>  a2 


and  the  result  follows. 
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The  case  [seq2]-  Then  (Si; S2, <ti)  -4  (S2,c'i)  because  (Si , 01)  — 4  a[ .  Once  again 
by  Lemma  2.16,  live  is  a  solution  to  LV-(Si)  and  thus  by  the  induction  hypothesis 
there  exists  cr'2  such  that: 

{S  1,0-2)  -4  ff'2  and  a[  ~x(/n/t(Si))  a2 

Now 

{(£,  init(S2))  1 £  €  final(Si)}  C  fiow(Si\ S2) 
and  by  Lemma  2.14,  final  (Si)  =  (init(Si)}.  Thus  by  Lemma  2.20 

o'l  ~N(init(S2))  a'l 

and  the  result  follows. 

The  case  [t/J.  Then  (if  [6]*  then  Si  else  S2,  ui)  -4  (Si ,  <Ji)  because  Sfbjci  = 
true.  Since  <ri  ~jv(<)  C2  and  N(£)  —  livetntry(£)  2  FV(b),  we  also  have  that 
B[b]<T2  =  true  (the  value  of  b  is  only  affected  by  the  variables  occurring  in  it)  and 
thus: 

(if  [6]*  then  Si  else  S2,c2)  — 4  (Si, 0-2) 

From  the  specification  of  the  constraint  system,  N(£)  =  liveentry(£)  2  liveezit(£)  = 
X(£)  and  hence  o\  ~x(t)  Since  (£,init(S  1))  €  fiow(S),  Lemma  2.22  gives 
ci  ~Ar(init(Si))  ff2  as  required. 

The  case  [t/2]  is  similar  to  the  previous  case. 

The  case  [tu/ii].  Then  (while  [6]'  do  S,ffi)—>(S;  while  [6]*  do  S,  or )  because  B[b\cri 
=  true.  Since  ci  ~w(«)  C2  and  IV(f)  3  FV(b),  we  also  have  that  B[b]a2  =  true  and 
thus 

(while  [6]*  do  S,  (S;  while  [6]*  do  S,c 2) 

and  again,  since  N(£)  =  liveentry(£)  2  liveczit(£)  =  X(£)  we  have  <xi  ~x(/)  c2  and 
then 

Cl  ~N(init(S ))  C2 

follows  from  Lemma  2.20  because  (£,  init(S))  €  fiow( while  [b]*  do  S). 

The  case  [iu/12].  Then  (while  [&]*  do  S,cri)  -4  o\  because  S[bjcr  1  =  false.  Since 
ci  ~n(()  C2  and  IV(f)  D  FV(b),  we  also  have  that  S[6]er2  =  false  and  thus: 

(while  [6]*  do  S,cr2)  —4  C2 

From  the  specification  of  W~(S),  we  have  N(£)  =  liveentry(£)  2  liveexit(£)  =  2f(f) 
and  thus  ci  ~x(t)  C2. 

This  completes  the  proof.  ■ 

Finally,  we  have  an  important  corollary  which  lifts  the  previous  result  to 
program  executions:  (i)  in  the  case  where  the  derivation  sequence  has  not 
yet  terminated  and  (ii)  in  the  case  it  has  terminated: 

Corollary  2.22  If  live  (=  LV-(S)  (with  S  being  label  consistent)  then: 

(i)  if  (5,  ci)  —4*  (S',  o[)  and  ci  ~N(init(S))  °2  then  there  exists  a'2  such 
that  (S,c2)  -4*  (S',a'2)  and  c(  ~N(in;t(S'))  c2,  and 
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(ii)  if  (5, a\)  -»*  cr[  and  a\  ~N(init(S))  then  there  exists  cr'2  such  that 
(5,0-2)  — >*  o'2  and  <j[  ~x(<)  &2  f°r  some  £  6  final(S). 

Proof  The  proof  is  by  induction  on  the  length  of  the  derivation  sequence  and  uses 
Theorem  2.21.  ■ 

Remark.  We  have  now  proved  the  correctness  of  Live  Variables  Analysis 
with  respect  to  a  small  step  operational  semantics.  Obviously,  the  correctness 
of  the  analysis  can  also  be  proved  with  respect  to  other  kinds  of  semantics. 
However,  note  that  if  one  relies  on,  say,  a  big  step  (or  natural)  semantics  then 
it  is  not  so  obvious  how  to  express  (and  prove)  the  correctness  of  looping 
computations:  in  a  big  step  semantics  a  looping  computation  is  modelled  by 
the  absence  of  an  inference  tree  -  in  contrast  to  the  small  step  semantics 
where  it  is  modelled  by  an  infinite  derivation  sequence.  ■ 
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Despite  the  differences  between  the  analyses  presented  in  Section  2.1,  there 
are  sufficient  similarities  to  make  it  plausible  that  there  might  be  an  un¬ 
derlying  framework.  The  advantages  that  accrue  from  identifying  such  a 
framework  include  the  possibility  of  designing  generic  algorithms  for  solving 
the  data  flow  equations,  as  we  will  see  in  Section  2.4. 


The  overall  pattern.  Each  of  the  four  classical  analyses  (presented  in 
Subsection  2.1.1  to  2.1.4)  considers  equations  for  a  label  consistent  program 
5*  and  they  take  the  form 


Analysis0{£) 


[1  \iizE 

1  |J{  Analysis.  (£')  |  (£',£)  G  F}  otherwise 


Analysis,(£) 


ft(Analysis0{£)) 


where 

•  U  is  fl  °r  U  (and  LI  is  U  or  n), 

•  F  is  either  ffow(5*)  or  flow*1^*), 

•  E  is  {inifc(5*)}  or  final(5*), 

•  l  specifies  the  initial  or  final  analysis  information,  and 

•  ft  is  the  transfer  function  associated  with  Bl  e  blocks(SiK). 

We  now  have  the  following  characterisation: 
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•  The  forward  analyses  have  F  to  be  flow(S*)  and  then  Analysis0  con¬ 
cerns  entry  conditions  and  Analysis ,  concerns  exit  conditions;  also  the 
equation  system  presupposes  that  S*  has  isolated  entries. 

•  The  backward  analyses  have  F  to  be  ffow^S*)  and  then  Analysis0 
concerns  exit  conditions  and  Amdysis,  concerns  entry  conditions;  also 
the  equation  system  presupposes  that  5*  has  isolated  exits. 


The  principle  we  have  seen  emerging  in  Section  2.1  is  that: 


•  When  U  is  D  we  require  the  greatest  sets  that  solve  the  equations 
and  we  are  able  to  detect  properties  satisfied  by  all  paths  of  execution 
reaching  (or  leaving)  the  entry  (or  exit)  of  a  label;  these  analyses  are 
often  called  must  analyses. 

•  When  |J  is  (J  we  require  the  least  sets  that  solve  the  equations  and  we 
are  able  to  detect  properties  satisfied  by  at  least  one  execution  path  to 
(or  from)  the  entry  (or  exit)  of  a  label;  these  analyses  are  often  called 
may  analyses. 


Remark.  Some  authors  propose  a  typology  for  Data  Flow  Analysis,  char¬ 
acterising  each  analysis  by  a  triple  from 

{fl’lJ}  * 't"4’ *“}  x  {t»4-} 

where  ->  means  forwards,  «-  means  backwards,  4-  means  smallest  and  t  means 
largest.  This  leads  to  eight  possible  types  of  analysis  -  a  cube.  In  fact,  given 
our  association  of  f)  with  f  and  |J  with  4,  the  cube  collapses  to  a  square. 
We  have  presented  analyses  of  the  following  four  types:  (("),  — t),  (U>  —>,4), 

(n><~>T)  and  (U.+-.4)-  ■ 

It  is  occasionally  awkward  to  have  to  assume  that  forward  analyses  have  iso¬ 
lated  entries  and  that  backward  analyses  have  isolated  exits.  This  motivates 
reformulating  the  above  equations  to  be  of  the  form 


Analysis0(£) 


Analysis,  {l) 


jj { Analysis,  (£')  |  {£',£)  £  F}  LI  4 


where  ilE  - 


{ 


i 

1 


if  £  G  E 
i  il$E 


fi(Analysis0(£)) 


where  X  satisfies  l  U  X  =  l  (hence  X  is  not  really  there).  This  formulation 
makes  sense  also  for  analyses  that  do  not  have  isolated  entries  and  exits. 

In  this  section,  we  present  a  more  formal  approach  to  defining  data  flow 
frameworks  that  exploits  the  similarities  that  we  have  identified  above.  Noth¬ 
ing  that  we  present  in  this  section  is  dependent  on  the  definition  of  elementary 
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blocks,  or  the  programming  language  constructs;  however,  the  techniques  do 
not  directly  apply  to  languages  with  procedures  (which  will  be  addressed  in 
Section  2.5).  The  view  that  we  take  here  is  that  a  program  is  a  transition 
system ;  the  nodes  represent  blocks  and  each  block  has  a  transfer  function  as¬ 
sociated  with  it  that  specifies  how  the  block  acts  on  the  “input”  state.  (Note 
that  for  forward  analyses,  the  input  state  is  the  entry  state,  and  for  backward 
analyses,  it  is  the  exit  state.) 

2.3.1  Basic  Definitions 

Property  spaces.  One  important  ingredient  in  the  framework  is  the 
property  space,  L,  used  to  represent  the  data  flow  information  as  well  as 
the  combination  operator,  |J  :  V(L)  ->  L,  that  combines  information  from 
different  paths;  as  usual  LI  :  L  x  L  ->  L  is  defined  by  l\  LI  l2  =  |J0i>M 
and  we  write  ±  for  (J  0.  It  is  customary  to  demand  that  this  property  space 
is  in  fact  a  complete  lattice;  as  discussed  in  Appendix  A  this  just  means 
that  it  is  a  partially  ordered  set,  ( L ,  C),  such  that  each  subset,  Y ,  has  a 
least  upper  bound,  |J  Y.  Looking  ahead  to  the  task  of  implementing  the 
analysis  one  often  requires  that  L  satisfies  the  Ascending  Chain  Condition-, 
as  discussed  in  Appendix  A  this  means  that  each  ascending  chain,  ( /„)„ , 
i.e.  l\  C  l2  C  /3  C  •  •  •,  eventually  stabilises,  i.e.  3 n:ln  —  /„+ 1  =  •  •  •• 

Example  2.23  For  Reaching  Definitions  we  have  L  =  ^(Var*  x  Lab*) 
and  it  is  partially  ordered  by  subset  inclusion,  i.e.  “C”  is  “C”.  Similarly,  []Y 
is  (J  5^,  U  l2  is  li  U  l2,  and  ±  is  0.  That  L  satisfies  the  Ascending  Chain 
Condition,  i.e.  that  Zj  C  l2  C  •  ■  •  implies  3 n:ln  =  ln+i  =  •  •  •,  follows  because 
Var*  x  Lab*  is  finite  (unlike  Var  x  Lab).  ■ 


Example  2.24  For  Available  Expressions  we  have  L  =  ^(AExp*)  and 
it  is  partially  ordered  by  superset  inclusion,  i.e.  “C”  is  “D” .  Similarly,  [J  Y 
is  f|E,  li  U  l2  is  l\  n  l2,  and  X  is  AExp*.  That  L  satisfies  the  Ascending 
Chain  Condition,  i.e.  that  l\  D  h  2  •  *  •  implies  3 n  :  ln  =  ln+ 1  =  •  •  •,  follows 
because  AExp*  is  finite  (unlike  AExp) .  ■ 

Remark.  Historically,  the  demands  on  the  property  space,  L,  have  often 
been  expressed  in  a  different  way.  A  join  semi-lattice  is  a  non-empty  set, 
L,  with  a  binary  join  operation,  U,  which  is  idempotent,  commutative  and 
associative,  i.e.  I  U  l  =  l,  li  U  l2  =  l2  U  l\  and  (l\  U  l2)  U  I3  =  li  LJ  ( l2  U  I3). 
The  commutativity  and  associativity  of  the  operation  mean  that  it  does  not 
matter  in  which  order  we  combine  information  from  different  paths.  The  join 
operation  induces  a  partial  ordering,  C,  on  the  elements  by  taking  l\  C  l2 
if  and  only  if  l\  U  l2  =  l2.  It  is  not  hard  to  show  that  this  in  fact  defines 
a  partial  ordering  and  that  h  U  l2  is  the  least  upper  bound  (with  respect  to 
C).  A  unit  for  the  join  operation  is  an  element,  ±,  such  that  1  LJ  Z  =  l.  It  is 
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not  hard  to  show  that  the  unit  is  in  fact  the  least  element  (with  respect  to 
Q.  It  has  been  customary  to  demand  that  the  property  space,  L,  is  a  join 
semi-lattice  with  a  unit  and  that  it  satisfies  the  Ascending  Chain  Condition. 
As  proved  in  Lemma  A.8  of  Appendix  A  this  is  equivalent  to  our  assumption 
that  the  property  space,  L,  is  a  complete  lattice  satisfying  the  Ascending 
Chain  Condition.  ■ 

Some  formulations  of  Monotone  Frameworks  are  expressed  in  terms  of  prop¬ 
erty  spaces  satisfying  a  Descending  Chain  Condition  and  using  a  combination 
operator  ["] .  It  follows  from  the  principle  of  lattice  duality  (see  the  Conclud¬ 
ing  Remarks  of  Chapter  4)  that  this  does  not  change  the  notion  of  Monotone 
Framework. 

Transfer  functions.  Another  important  ingredient  in  the  framework  is 
the  set  of  transfer  functions,  ft  :  L  ->  L  for  t  G  Lab*.  It  is  natural  to  demand 
that  each  transfer  function  is  monotone,  i.e.  I  C  V  implies  ft(l)  C  /*(/'). 
Intuitively,  this  says  that  an  increase  in  our  knowledge  about  the  input  must 
give  rise  to  an  increase  in  our  knowledge  about  the  output  (or  at  the  least 
that  we  know  the  same  as  before).  Formally,  we  shall  see  that  monotonicity 
is  of  importance  for  the  algorithms  we  develop.  To  control  the  set  of  transfer 
functions  we  demand  that  there  is  a  set  T  of  monotone  functions  over  L, 
fulfilling  the  following  conditions: 

•  T  contains  all  the  transfer  functions  ft  in  question, 

•  T  contains  the  identity  function,  and 

•  T  is  closed  under  composition  of  functions. 

The  condition  on  the  identity  function  is  natural  because  of  the  skip  state¬ 
ment  and  the  condition  on  composition  of  functions  is  natural  because  of 
the  sequencing  of  statements.  Clearly  one  can  take  T  to  be  the  space  of 
monotone  functions  over  L  but  it  is  occasionally  advantageous  to  consider  a 
smaller  set  because  it  makes  it  easier  to  find  compact  representations  of  the 
functions. 

Some  formulations  of  Monotone  Frameworks  associate  transfer  functions  with 
edges  (or  flows)  rather  than  nodes  (or  labels).  A  similar  effect  can  be  obtained 
using  the  approach  of  Exercise  2.11. 

Frameworks.  In  summary,  a  Monotone  Framework  consists  of: 

•  a  complete  lattice,  L,  that  satisfies  the  Ascending  Chain  Condition, 
and  we  write  |J  for  the  least  upper  bound  operator;  and 

•  a  set  T  of  monotone  functions  from  L  to  L  that  contains  the  identity 
function  and  that  is  closed  under  function  composition. 
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Note  that  we  do  not  demand  that  T  is  a  complete  lattice  or  even  a  partially 
ordered  set  although  this  is  the  case  for  the  set  of  all  monotone  functions 
from  L  to  L  (see  Appendix  A). 

A  somewhat  stronger  concept  is  that  of  a  Distributive  Framework.  This  is  a 
Monotone  Framework  where  additionally  all  functions  /  in  T  axe  required  to 
be  distributive: 

m  u  h)  =  m)  □  f(h) 

Since  /(Zi  U/2)  3  /(Zi)  U  f{h)  follows  from  monotonicity,  the  only  additional 
demand  is  that  f(l\  U  I2)  C  f(h)  LI  f(l 2).  When  this  condition  is  fulfilled  it 
is  sometimes  possible  to  get  more  efficient  algorithms. 

Instances.  The  data  flow  equations  make  it  clear  that  more  than  just 
a  Monotone  (or  Distributive)  Framework  is  needed  in  order  to  specify  an 
analysis.  To  this  end  we  define  an  instance ,  Analysis,  of  a  Monotone  (or 
Distributive)  Framework  to  consist  of: 


•  the  complete  lattice,  L,  of  the  framework; 

•  the  space  of  functions,  T,  of  the  framework; 

•  a  finite  flow,  F,  that  typically  is  f?ow(S*)  or  fiowR(Si,)-, 

•  a  finite  set  of  so-called  extremal  labels,  E,  that  typically  is  (init(5*)} 
or  finals*); 

•  an  extremal  value,  l  G  L,  for  the  extremal  labels;  and 

•  a  mapping,  /.,  from  the  labels  Lab*  of  F  and  E  to  transfer  functions 
in  T. 


The  instance  then  gives  rise  to  a  set  of  equations,  Analysis-,  of  the  form 
considered  earlier: 


AnaJysisa(£)  =  |_J{Anafysis.(^')  |  {£',£)  €  F}  U  ilB 
1  1  (  1  if  ^  e  J5? 

where  ^  ±  iU^E 

Analysis,  (£)  =  ft  ( Analysis,,  {£) ) 

It  also  gives  rise  to  a  set  of  constraints,  Analysis-,  defined  by: 

Analysis0(£)  □  |_J{ Analysis. (O  |  (£',£)  €  F}  U  ifE 
where  ilE  =  j  l±  ^ 
Analysis,(£)  □  ft(Analysis0(£)) 


'£eE 

'£(£E 
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ft 

ft(l)  —  (l\  kill([B]e))  U  gen([jB]<)  where  [B]e  £  blocks(S *) 

Figure  2.6:  Instances  for  the  four  classical  analyses. 


2.3.2  The  Examples  Revisited 

We  now  return  to  the  four  classical  analyses  from  Section  2.1  and  show  how 
the  analyses  of  a  label  consistent  program,  S*,  can  be  recast  as  an  instance  of 
a  Monotone  (in  fact  Distributive)  Framework.  We  refer  to  Figure  2.6  for  all 
the  data  needed  to  specify  the  Monotone  Framework  as  well  as  the  instance. 

It  is  immediate  that  the  property  space,  L,  is  a  complete  lattice  in  all  cases. 
Given  the  choice  of  a  partial  ordering,  C,  the  information  about  the  least 
element,  X,  and  the  least  upper  bound  operation,  |J,  is  immediate.  Note 
that  we  define  C  to  be  C  for  those  analyses  where  we  used  |J  (and  require 
the  least  solution)  in  Section  2.1,  and  similarly,  that  we  define  C  to  be  D 
for  those  analyses  where  we  used  f)  (and  required  the  greatest  solution)  in 
Section  2.1.  To  ensure  that  L  satisfies  the  Ascending  Chain  Condition  we  have 
restricted  the  attention  to  the  finite  sets  of  expressions,  labels  and  variables 
occurring  in  the  program,  5*,  under  consideration. 

The  definition  of  the  flow,  F,  is  as  one  should  expect:  it  is  flow(S*)  for  forward 
analyses  and  fiowR(S*)  for  backward  analyses.  Similarly,  the  extremal  labels, 
E  are  (init(S*)}  for  forward  analyses  and  finai(5*)  for  backward  analyses. 
The  only  thing  to  note  about  the  extremal  value,  i,  is  that  there  seems  to  be 
no  general  pattern  concerning  how  to  define  it:  it  is  not  always  T i  (nor  is  it 
always  !_/,). 

It  remains  to  show  that  the  conditions  on  the  set  T  of  transfer  functions  are 
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satisfied. 

Lemma  2.25  Each  of  the  four  data  flow  analyses  in  Figure  2.6  is  a  Mono¬ 
tone  Framework  as  well  as  a  Distributive  Framework.  ■ 

Proof  To  prove  that  the  analyses  are  Monotone  Frameworks  we  just  have  to 
confirm  that  7  has  the  necessary  properties: 

The  functions  of  7  are  monotone:  Assume  that  l  C  l'.  Then  (l  \  4)  E  (l'  \  4) 
and,  therefore  ((l  \  4)  U  lg)  C  ((/'  \  4)  U  lg)  and  thus  f(l)  E  /(/')  as  required. 
Note  that  this  calculation  is  valid  regardless  of  whether  C  is  C  or  D. 

The  identity  function  is  in  7\  It  is  obtained  by  taking  both  4  and  lg  to  be  0. 

The  function  of  7  are  closed  under  composition:  Suppose  }(l)  =  (l  \  4)  U  lg  and 

f'(l)  =  (l  \  l'k)  U  l'g.  Then  we  calculate: 

=  (((f  \  i'k)  u  ig)  \  ik)  u  ig 

=  {/  \  ( 4  U  4))  U  (( l'g  \  4)  u  lg) 

So  (/  O  /')(/)  =  (I  \  4')  U  I"  where  I'i  =  l'k  U  4  and  lg  =  (l'g  \  4)  U  lg.  This 
completes  the  proof  of  the  first  part  of  the  lemma. 

To  prove  that  the  analyses  are  Distributive  Frameworks  consider  f  &  7  given  by 
f(l)  =  (I  \  4)  U  lg.  Then  we  have: 

f(l  U  /')  =  ((l  U  l1)  \  4)  U  lg 

=  (( l  \.4)  u  ( l '  \  4))  u  lg 

=  ((l  Vfic)  U  lg)  U  ((/'  \  4)  U  lg) 

=  hi)  u  m 

Note  that  the  above  calculation  is  valid  regardless  of  whether  U  is  U  or  n.  This 
completes  the  proof.  ■ 

It  is  worth  pointing  out  that  in  order  to  get  this  result  we  have  made  the 
frameworks  dependent  upon  the  actual  program  -  this  is  needed  to  enforce 
that  the  Ascending  Chain  Condition  is  fulfilled. 

Example  2.26  Let  us  return  to  the  Available  Expressions  Analysis  of  the 
program 

[x:=a+b]1-,  [y:=a*b]2;  while  [y>a+b]3  do  ([a:=a+l]4;  [x:=a+b]5) 

of  Examples  2.4  and  2.5  and  let  us  specify  it  as  an  instance  of  the  associated 
Monotone  Framework.  The  complete  lattice  of  interest  is 

CP({a+b,a*b,a+l}),D) 

with  least  element  {a+b,  a*b,  a+1}.  The  set  of  transfer  functions  has  the  form 
shown  in  Figure  2.6. 
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The  instance  of  the  framework  additionally  has  the  flow  {(1,2),  (2, 3),  (3, 4), 
(4, 5),  (5, 3)}  and  the  set  of  extremal  labels  is  {1}.  The  extremal  value  is  0 
and  the  transfer  functions  associated  with  the  labels  are 


f^(Y) 

=  Y  U  {a+b} 

fFOO 

=  YU  {a*b} 

£ 

LU 

=  YU  {a+b} 

fF<X) 

=  Y  \  {a+b, a*b, a+l} 

f£E(Y) 

=  YU  {a+b} 

for  Y  C  {a+b,  a*b,  a+l}.  ■ 

2.3.3  A  Non-distributive  Example 

Lest  the  reader  should  imagine  that  all  Monotone  Frameworks  are  Distribu¬ 
tive  Frameworks,  here  we  present  one  that  is  not.  The  Constant  Propagation 
Analysis  will  determine: 

For  each  progiam  point,  whether  or  not  a  variable  has  a  constant 
value  whenever  execution  reaches  that  point. 

Such  information  can  be  used  a*  the  basis  for  an  optimisation  known  as 
Constant  Folding:  all  uses  of  the  Variable  may  be  replaced  by  the  constant 
value. 

The  Constant  Propagation  framework.  The  complete  lattice 
used  for  Constant  Propagation  Analysis  of  a  program,  5*,  is 

StateCp  =  ((Var*  ->  ZT)±,  C, U,  n,  X,  Aas.T) 

where  Var*  is  the  set  of  variables  appearing  in  the  program  and  ZT  =  ZU{T} 
is  partially  ordered  as  follows: 

V2€Zt:zCT 

V.2i,  z2  €  Z  :  (zi  C  z2)  <=>  (zi  =  z2) 


The  top  element  of  ZT  is  used  to  indicate  that  a  variable  is  non-constant  and 
all  other  elements  indicate  that  the  value  is  that  particular  constant.  The 
idea  is  that  an  element  a  of  Var*  — ¥  ZT  is  a  property  state:  for  each  variable 
x,  cr(x)  will  give  information  about  whether  or  not  x  is  a  constant  and  in  the 
latter  case  which  constant. 

To  capture  the  case  where  no  information  is  available  we  extend  Var*  ->  ZT 
with  a  least  element  X,  written  (Var*  — >  ZT)j_.  The  partial  ordering  C  on 
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Acp  ■  AExp  -4  (Statecp  -4  Zj) 


.  i  _  f  -L  if  5  =  J_ 
cp  [a:]  tr  |  5(x)  otherwise 


ACp[n]5  =  j  ^ 


if  cr  =  jL 
otherwise 


Acpjai  opa  02]?  =  Azp[ax]d  op0  Acpfajd 
transfer  functions:  ffp 


1/  ,  ,cp/^\  _  j  - L  if  o  —  X 

~  a‘  'a'  ~  \  a[x  h->  ,4cpM<7]  otherwise 


skip]*  : 
b}1: 


ftP(e)  =  ° 
ftP($)  =  ° 


Table  2.7:  Constant  Propagation  Analysis. 


Statecp  =  (Var*  -4  ZT)X  is  defined  by 
Vct  €  (Var*  -4  ZT)X  :  1C5 

V5i,52  G  Var*  -4  ZT  :  o\  C  ?2  iff  Vi :  ffi(a:)  C  02(2;) 
and  the  binary  least  upper  bound  operation  is  then: 

V<7  G  (Var*  -4  ZT)X  :  5U±  =  ct  =  ±US: 

Vdi,$2  G  Var*  -4  ZT  :  Va; :  (ai  U  <72)(x)  =  ^i(a:)  LI  02(2;) 

In  contrast  to  the  earlier  examples,  we  define  the  transfer  functions  as  follows: 

J~cp  =  {/  |  /  is  a  monotone  function  on  Statecp} 

It  is  easy  to  verify  that  Statecp  and  .Fcp  satisfy  the  requirements  of  being  a 
Monotone  Framework  (see  Exercise  2.8). 

Constant  Propagation  is  a  forward  analysis,  so  for  the  program  5*  we  take 
the  flow,  F ,  to  be  fiow(5*),  the  extremal  labels,  E,  to  be  {init(S*)},  the 
extremal  value,  icp,  to  be  Aa:.T,  and  the  mapping,  /.cp,  of  labels  to  transfer 
functions  is  given  in  Table  2.7.  The  specification  of  the  transfer  functions 
uses  the  function 

Acp  :  AExp  -4  (Statecp  -4  Zx) 

for  analysing  expressions.  Here  the  operations  on  Z  are  lifted  to  Zj_  = 
ZU{1,T}  by  taking  z\  opa  22  =  21  opa  22  if  21,22  G  Z  (and  where  opa  is 
the  corresponding  arithmetic  operation  on  Z),  21  opQ  22  =  X  if  21  =  X  or 
22  =  X  and  21  op0  22  =  T  otherwise. 


72 


DATA  FLOW  ANALYSIS 


Lemma  2.27  Constant  Propagation  is  a  Monotone  Framework  that  is  not 
a  Distributive  Framework.  ■ 

Proof  The  proof  that  Constant  Propagation  is  a  Monotone  Framework  is  left  for 
Exercise  2.8.  To  show  that  it  is  not  a  Distributive  Framework  consider  the  transfer 
function  /f  p  for  [y :  =x*x]<  and  let  <ti  and  02  be  such  that  d\  (x)  =  1  and  <72  (x)  =  —1. 
Then  o\  U  02  maps  x  to  T  and  thus  ffp(S  1  U  02)  maps  y  to  T  and  hence  fails  to 
record  that  y  has  the  constant  value  1.  However,  both  /fP(5i)  and  /fp(? 2)  map  y 
to  1  and  so  does  ffp(o  1)  U  /fP(? 2).  ■ 

Correctness  of  the  analysis  will  be  established  in  Section  4.5. 


2.4  Equation  Solving 

Having  set  up  a  framework,  there  remains  the  question  of  how  to  use  the 
framework  to  obtain  an  analysis  result.  In  this  section  we  shall  consider  two 
approaches.  One  is  an  iterative  algorithm  in  the  spirit  of  Chaotic  Iteration 
as  presented  in  Section  1.7.  The  other  more  directly  propagates  analysis 
information  along  paths  in  the  program. 

2.4.1  The  MFP  Solution 

We  first  present  a  general  iterative  algorithm  for  Monotone  Frameworks  that 
computes  the  least  solution  to  the  data  flow  equations.  Historically,  this 
is  called  the  MFP  solution  (for  Maximal  Fixed  Point)  although  it  in  fact 
computes  the  least  fixed  point;  the  reason  is  that  the  classical  literature 
tends  to  focus  on  analyses  where  U  is  n  rather  than  U  (and  because  the  least 
fixed  point  with  respect  to  D  equals  the  greatest  fixed  point  with  respect  to 

C).  ' 

The  algorithm,  written  in  pseudo-code  in  Table  2.8,  takes  as  input  an  instance 
of  a  Monotone  Framework.  It  uses  an  array,  Analysis,  which  contains  the 
Analysis0  information  for  each  elementary  block;  the  array  is  indexed  by 
labels.  It  also  uses  a  worklist  W  being  a  list  of  pairs;  each  pair  is  an  element 
of  the  flow  relation  F.  The  presence  of  a  pair  in  the  worklist  indicates  that 
the  analysis  has  changed  at  the  exit  of  (or  entry  to  -  for  backward  analyses) 
the  block  labelled  by  the  first  component  and  so  must  be  recomputed  at  the 
entry  to  (or  exit  from)  the  block  labelled  by  the  second  component.  As  a 
final  stage  the  algorithm  presents  the  result  (MFP 0,  MFP,)  of  the  analysis 
in  a  form  close  to  the  formulation  of  the  data  flow  equations. 

Example  2.28  To  illustrate  how  the  algorithms  works  let  us  return  to 
Example  2.26  where  we  consider  the  program 

[x^a+b]1;  [y:=a*b]2; while  [y>a+b]3  do  ([a:=a+l]4;  [x:=a+b]5) 
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INPUT:  An  instance  of  a  Monotone  Framework: 

(L,F,F,E,c,f.) 

OUTPUT:  MFP0,MFP. 


METHOD:  Step  1:  Initialisation  (of  W  and  Analysis) 
W  :=  nil; 

for  all  (£,£')  in  F  do 
W  :=  cons((^F),W); 
for  all  £  in  F  or  F  do 

if  l  €  E  then  Analysis[£]  :=  i 

else  Analysis^]  :=  ±l; 


Step  2:  Iteration  (updating  W  and  Analysis) 
while  W  nil  do 

t  :=  fst(head(W));  i'  =  snd(head(W)); 

W  :=  tail(W); 

if  /*(Analysis[£])  %  AnalysisfF]  then 

Analysis[P]  :=  Analysis[F]  U  /*(Analysis[£]); 
for  all  £"  with  {£',£")  in  F  do 
W  :=  cons((F,n.W); 

Step  3:  Presenting  the  result  (MFP0  and  MFP,) 
for  all  i  in  F  or  E  do 
MFP0{C)  :=  Analysis[€]; 

MFP.{i)  :=  //(Analysis^) 


Table  2.8:  Algorithm  for  solving  data  flow  equations. 


Writing  W  for  the  list  ((2, 3), (3, 4), (4, 5), (5, 3))  and  U  for  the  set  (a+b,  a*b, 
a+l},  step  1  of  the  algorithm  will  initialise  the  data  structures  as  in  the  first 
row  in  Table  2.9.  Step  2  will  inspect  the  first  element  of  the  worklist  and 
rows  2-7  represent  cases  where  there  is  a  change  in  the  array  Analysis  and 
hence  a  new  pair  is  placed  on  top  of  the  worklist;  it  is  inspected  in  the  next 
iteration.  Rows  8-12  represent  cases  where  no  modification  is  made  in  the 
array  and  hence  the  worklist  is  getting  smaller  -  the  elements  of  W  are  now 
inspected.  Step  3  will  then  produce  the  solution  we  already  saw  in  Example 
2.5.  ■ 

Properties  of  the  algorithm.  We  shall  first  show  that  the  algorithm 
computes  the  expected  solution  to  the  equation  system. 

Lemma  2.29  The  worklist  algorithm  in  Table  2.8  always  terminates  and 
it  computes  the  least  (or  MFP)  solution  to  the  instance  of  the  framework 
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Analysis^]  for  £  being 

W 

1 

2 

3 

4 

5 

1 

((1,2  ),W) 

0 

U 

U 

U 

U 

2 

((2,3  ),W) 

0 

{a+b} 

U 

U 

U 

3 

((3, 4), WO 

0 

{a+b} 

{a+b,a*b} 

u 

u 

4 

((4,5  ),W) 

0 

{a+b} 

{a+b,a*b} 

{a+b,a*b} 

u 

5 

((5,3 ),W) 

0 

{a+b} 

{a+b,a*b} 

{a+b,a*b} 

6 

((3, 4), WO 

'HI' ' 

{a+b} 

{a+b} 

{a+b,a*b} 

0 

7 

((4, 5), WO 

0 

{a+b} 

{a+b} 

{a+b} 

aw-.M 

8 

((2,3),- ••) 

0 

{a+b} 

{a+b} 

{a+b} 

0 

9 

((3,4),- ••) 

0 

{a+b} 

{a+b} 

{a+b} 

0 

10 

((4,5),- ••) 

0 

{a+b} 

{a+b} 

{a+b} 

11 

((5,3)) 

0 

{a+b} 

{a+b} 

{a+b} 

0 

12 

0 

0 

{a+b} 

{a+b} 

{a+b} 

0 

Table  2.9:  Iteration  steps  of  the  worklist  algorithm 


given  as  input.  ■ 

Proof  First  we  prove  the  termination  result.  Step  1  and  3  are  bounded  loops  over 
finite  sets  and  thus  trivially  terminate.  Next  consider  step  2.  Assume  that  there 
are  6  labels  in  the  program.  Then  the  worklist  initially  has  at  most  b2  elements; 
the  worst  case  is  that  F  associates  every  label  to  every  label.  Each  iteration  either 
deletes  an  element  from  the  worklist  or  adds  up  to  b  new  elements.  New  elements 
are  added  if  for  the  pair  selected  in  this  iteration,  (£,£'),  we  have  //(Analysis[£])  g 
Analysis[f'];  that  is,  /<(Analysis[f])  3  Analysis[f']  or  they  are  incomparable.  In  either 
case,  the  new  value  of  Analysis^']  is  strictly  greater  than  the  previous  one.  Since 
the  set  of  values  satisfies  the  Ascending  Chain  Condition,  this  can  only  happen  a 
finite  number  of  times.  Thus  the  worklist  will  eventually  be  exhausted. 

Next  we  prove  the  correctness  result.  Let  Analysis0  and  Analysis .  be  the  least 
solution  to  the  instance  given  as  input  to  the  algorithm.  The  proof  is  now  in  three 
parts:  (i)  first  we  show  that  on  each  iteration  the  values  in  Analysis  are  approxi¬ 
mations  to  the  corresponding  values  of  Analysis0 ,  (ii)  then  we  show  that  Analysis0 
is  an  approximation  to  Analysis  at  the  termination  of  step  2  of  the  algorithm,  and 
(iii)  finally  we  combine  these  results. 

Part  (i).  We  show  that 


W  :  Analysisff]  C  Analysis0 (£) 

is  an  invariant  of  the  loop  of  step  2.  After  step  I  we  have  Analysis[f]  C  Analysis0(£) 
for  all  l  because  AnaJysis0  (£)  3  i  whenever  l  E  E.  After  each  iteration  through  the 
loop  either  there  is  no  change  because  the  iteration  just  deletes  an  element  from 
the  worklist  or  else  Analysis^"]  is  unchanged  for  all  £"  except  for  some  £' .  In  that 
case  there  is  some  £  such  that  {£,£')  €  F  and 

newAnalysis^j  =  oWAnalysisf^]  L)  /<(oIdAnalysis[f]) 
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C  Analysis0(F)  U  ft(Analysis0(£)) 

=  Analysis0  (?) 

The  inequality  follows  since  ft  is  monotone  and  the  last  equation  follows  from 
(Analysis0,  Analysis ,)  being  a  solution  to  the  instance. 

Part  (ii).  On  termination  of  the  loop,  the  worklist  is  empty.  We  show  that 

V£,d  ■  (£,(!)  Analysis^]  □  /<(Analysis[F]) 

by  contradiction.  So  suppose  that  Analysis[F'J  2  //(Analysis[F])  for  some  (£,£')  € 
F  and  let  us  obtain  a  contradiction.  Consider  the  last  time  that  Analysis[F]  was 
updated.  If  this  was  in  step  1  we  considered  (£,£')  in  step  2  and  ensured  that 

Analy$is[f']  □  /*(Analysis[F]) 

and  this  invariant  has  been  maintained  ever  since;  hence  this  case  cannot  apply. 
It  follows  that  Analysis[F]  was  last  updated  in  step  2.  But  at  that  time  (F,  F')  was 
placed  in  the  worklist  once  again.  When  considering  (F ,  (!)  in  step  2  we  then  ensured 
that 

Analysis^]  □  /*(Analysis[F]) 

and  this  invariant  has  been  maintained  ever  since;  hence  this  case  cannot  apply 
either.  This  completes  the  proof  by  contradiction. 

On  termination  of  the  loop  we  have: 

VF  6  E  :  Analysis[F]  □  i 

This  follows  because  it  was  established  in  step  1  and  it  is  maintained  ever  since. 
Thus  it  follows  that  at  termination  of  step  2: 

VF  :  Analysis[F]  □  ([_)(/*' (Analysis^])  |  (C,£)  €  F})  U  4 

Part  (iii).  By  our  assumptions  and  Proposition  A. 10  we  have 

VF  :  MFP0 (F)  3  Analysis0(£) 

since  Analysis0(£ )  is  the  least  solution  to  the  above  constraint  system  and  MFP0 
equals  the  final  value  of  Analysis.  Together  with  part  (i)  this  proves  that 

VF  :  MFP0[F]  =  Analysis0(£ ) 

upon  termination  of  step  2.  ■ 

Based  on  the  proof  of  termination  in  Lemma  2.29  we  can  determine  an  upper 
bound  on  the  number  of  basic  operations  (for  example  an  application  of  ft, 
an  application  of  U,  or  an  update  of  Analysis)  performed  by  the  algorithm. 
For  this  we  shall  assume  that  the  flow  F  is  represented  in  such  a  way  (for 
example  an  array  of  lists)  that  all  (f',f")  emanating  from  £'  can  be  found  in 
time  proportional  to  their  number.  Suppose  that  E  and  F  contain  at  most 
b  >  1  distinct  labels,  that  F  contains  at  most  e  >  b  pairs,  and  that  L  has 
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finite  height  at  most  h  >  1.  Then  steps  1  and  3  perform  at  most  0(b  +  e) 
basic  operations.  Concerning  step  2  a  pair  is  placed  on  the  worklist  at  most 
0(h)  times,  and  each  time  it  takes  only  a  constant  number  of  basic  steps  to 
process  it  -  not  counting  the  time  needed  to  add  new  pairs  to  W;  this  yields 
at  most  0(e  ■  h)  basic  operations  for  step  2.  Since  h  >  1  and  e  >  b  this 
gives  at  most  0(e  •  h )  basic  operations  for  the  algorithm.  (Since  e  <  b2  a 
potentially  coarser  bound  is  0(b 2  •  h).) 

Example  2.30  Consider  the  Reaching  Definitions  Analysis  and  suppose 
that  there  are  at  most  v  >  1  variables  and  b  >  1  labels  in  the  program,  S*, 
being  analysed.  Since  L  =  "P(Var*  x  Lab*),  it  follows  that  h  <v-b  and  thus 
we  have  an  0(v  ■  b3)  upper  bound  on  the  number  of  basic  operations. 

Actually  we  can  do  better.  If  5*  is  label  consistent  then  the  variable  of  the 
pairs  (x,  l)  of  V(Vaxi,  x  Lab*)  will  always  be  uniquely  determined  by  the 
label  l  so  we  get  an  0(b3)  upper  bound  on  the  number  of  basic  operations. 
Furthermore,  F  is  flow(5*)  and  inspection  of  the  equations  for  flow(S*)  shows 
that  for  each  label  i  we  construct  at  most  two  pairs  with  t  in  the  first  com¬ 
ponent.  This  means  that  e  <  2  b  and  we  get  an  0(b2)  upper  bound  on  the 
number  of  basic  operations.  ■ 


2.4.2  The  MOP  Solution 

Let  us  now  consider  the  other  solution  method  for  Monotone  Frameworks 
where  we  more  directly  propagate  analysis  information  along  paths  in  the 
program.  Historically,  this  is  called  the  MOP  solution  (for  Meet  Over  all 
Paths)  although  we  do  in  fact  take  the  join  (or  least  upper  bound)  over 
all  paths  leading  to  an  elementary  block;  once  again  the  reason  is  that  the 
classical  literature  focuses  on  analyses  where  LI  is  D  rather  than  U. 

Paths.  For  the  moment,  we  adopt  the  informal  notion  of  a  path  to  the 
entry  of  a  block  as  the  list  of  blocks  traversed  from  the  start  of  the  program 
up  to  that  block  (but  not  including  it);  analogously,  we  can  define  a  path 
from  an  exit  of  the  block.  Data  Flow  Analyses  determine  properties  of  such 
paths.  Forward  analyses  concern  paths  from  the  initial  block  to  the  entry 
of  a  block;  backward  analyses  concern  paths  from  the  exit  of  a  block  to  a 
final  block.  The  effect  of  a  path  on  the  state  can  be  computed  by  composing 
the  transfer  functions  associated  with  the  individual  blocks  in  the  path.  In 
the  forward  case  we  collect  information  about  the  state  of  affairs  before  the 
block  is  executed  and  in  the  backward  case  we  collect  information  about  the 
state  of  affairs  immediately  after  the  block  has  been  executed.  This  informal 
description  contrasts  with  the  approach  taken  in  Section  2.1  and  earlier  in 
this  section;  there  we  presented  equations  which  were  defined  in  terms  of  the 
immediate  predecessors  (successors)  of  a  block  (as  defined  by  the  flow  and 
flow*1  functions).  We  will  see  later  that,  for  a  large  class  of  analyses,  these 
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two  approaches  coincide. 

For  the  formal  development  let  us  consider  an  instance  (L,F,F,E,i,  /.)  of 
a  Monotone  Framework.  We  shall  use  the  notation  £  =  [Ei,---,£n]  for  a 
sequence  of  n  >  0  labels.  We  then  define  two  sets  of  paths.  The  paths  up  to 
but  not  including  £  are 

path0(£ )  =  {[^i,  •  •  •  ,£n-i]  |  n  >  1  A  Vi  <  n  :  (£i,£i+ 1)  €  F  A  ln  =  l  A  t\  G  E} 
and  the  paths  up  to  and  including  t  are: 
path,(£)  =  {[<?i,  •  ••  ,£„]  |  n  >  1  A  Vi  <  n  :  (£i,£i+ 1)  G  F  A  £n  =  £  A^i  G  £1} 
For  a  path  /=  [fi ,  •  •  • ,  £n]  we  define  the  transfer  function 

f(  =  fh  °  id 

so  that  for  the  empty  path  we  have  /j  j  =  id  where  id  is  the  identity  function. 

By  analogy  with  the  definition  of  solutions  to  the  equation  system,  in  par¬ 
ticular  MFP0(£)  and  MFPm(£),  we  now  define  two  components  of  the  MOP 
solution.  The  solution  up  to  but  not  including  £  is 

MOP0(£)  =  □(/*<*)  |  £  €  patb0(£)} 

and  the  solution  up  to  and  including  £  is: 

MOP.{£)  =  |  £  e  path.(£)} 

Unfortunately,  the  MOP  solution  is  sometimes  uncomputable  (meaning  that 
it  is  undecidable)  even  though  the  MFP  solution  is  always  easily  computable 
(because  of  the  property  space  satisfying  the  Ascending  Chain  Condition); 
the  following  result  establishes  one  such  result: 

Lemma  2.31  The  MOP  solution  for  Constant  Propagation  is  undecid¬ 
able.  ■ 

Proof  Let  «i ,  •  •  • ,  un  and  t)i ,  •  •  • ,  vn  be  strings  over  the  alphabet  { 1  ,•  •  •  ,9}  (see  Ap¬ 
pendix  C).  The  Modified  Post  Correspondence  Problem  is  to  determine  whether  or 
not  there  exists  a  sequence  t'i ,  •  •  • ,  im  with  ii  =  1  such  that  u,-,  •  •  •  iz;m  =  Vi,  •  •  •  t><„ . 

Let  |  u  |  denote  the  length  of  the  string  u  and  let  [u]  be  its  value  interpreted  as  a 
natural  number.  Consider  the  program  (omitting  most  labels) 

x:=[«i];  y:=lvi]; 
while  [■  •  •]  do 

(if  [•  •  •]  then  x:=x  *  10'“^  +  [ui];  y:=y  *  +  [vi]  else 

if  [•••]  then  x:=x  *  +  [un];  y:=y  *  10^  +  [v„]  else  skip) 

[z:=abs((x-y)*(x-y))]< 


Vi 
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where  abs  gives  the  absolute  value  (which  is  1  for  a  positive  argument  and  0  or  —  1 
otherwise)  and  where  the  details  of  [•  •  •]  are  of  no  concern  to  us  (and  so  could  be 
taken  to  be  [true]). 

Then  MOP.(£)  will  map  z  to  1  if  and  only  if  the  Modified  Post  Correspondence 
Problem  has  no  solution.  Since  the  Modified  Post  Correspondence  problem  is  un- 
decidable  [57]  so  is  the  MOP  solution  for  Constant  Propagation  (assuming  that  our 
selection  of  arithmetic  operation  does  indeed  allow  those  used  to  be  defined).  ■ 

MOP  versus  MFP  solutions.  We  shall  shortly  prove  that  the  MFP 
solution  safely  approximates  the  MOP  solution  (informally,  MFP  □  MOP). 
In  the  case  of  a  (f|,  |)  or  (f),  t)  analysis,  the  MFP  solution  is  a  subset  of 

the  MOP  solution  (□  is  C);  in  the  case  of  a  ((J,  -t,|)  or  ((J,  «—,J.)  analysis, 
the  MFP  solution  is  a  superset  of  the  MOP  solution.  We  can  also  show 
that,  in  the  case  of  Distributive  Frameworks,  the  MOP  and  MFP  solutions 
coincide. 

Lemma  2.32  Consider  the  MFP  and  MOP  solutions  to  an  instance  (L,  T, 
F,  B,  l,  /.)  of  a  Monotone  Framework;  then: 

MFP0  □  MOPo  and  MFP .  □  MOP. 

If  the  framework  is  distributive  and  if  patha(£)  0  for  all  l  in  E  and  F  then: 
MFP0  =  MOP0'  and  MFP.  =  MOP. 

■ 

Proof  It  is  straightforward  to  show  that: 

W  :  MOP. (£)  C  ft(MOPo(£)) 

V£  :  MFP, (£)  =  ft(MFP0{£)) 

For  the  first  part  of  the  lemma  it  therefore  suffices  to  prove  that: 

Vf  :  MOPo{£)  C  MFP0{£) 

Note  that  MFP0  is  the  least  fixed  point  of  the  functional  F  defined  by: 

F(Ao)(£)  =  (\J{U  (A„(0)  I  (Cj)  e  F})  u  4 

Next  let  us  restrict  the  length  of  the  paths  used  to  compute  MOP0;  for  n  >  0 
define: 

MOP?(£)  =  |_|{/<W  I  *  e  path0(£),  \£\  <  n } 

Clearly,  MOP0(£)  =  [_|n  MOP™(£)  and  to  prove  MFP0  3  MOP0  is  therefore  suffices 
to  prove 


Vn  :  MFP0  3  MOPZ 
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and  we  do  so  by  numerical  induction.  The  basis,  MFP0  3  MOP^,  is  trivial.  The 
inductive  step  proceeds  as  follows: 

MFPo(i)  =  F(MFP0)(£) 

=  (U {ft-  (MFP.(0)  I  (tj)  €  F})  U  4 

3  (|_|{/*'  (MOPZ(O)  I  (4  e)  £  F})  U  4 

=  (UW‘)  I f  e  ^.(O,  I H  <  n»  I  (t,e)  £  F})  u  4 

3  1 1  €  PatMO,l*1  <  n}  I  (/',/)  €  F})  U  4 

=  |J({/^)  1  S  Path»W’ 1  <  1*1  <  «})  u  4 

=  MOP?+1(0 

where  we  have  used  the  induction  hypothesis  to  get  the  first  inequality.  This  com¬ 
pletes  the  proof  of  MFP0  3  MOP0  and  MFP ,  3  MOP , . 

To  prove  the  second  part  of  the  lemma  we  now  assume  that  the  framework  is 
distributive.  Consider  £  in  E  or  F.  By  assumption  ft  is  distributive,  that  is 
ft (l i  LI  I2)  =  ft(li)  U  ft(h),  and  from  Lemma  A. 9  of  Appendix  A  it  follows  that 

1  * e  y> 

whenever  Y  is  non-empty.  By  assumption  we  also  have  path0  (£)  ^  0  and  it  follows 
that 

/<(Uwo  1 1 G  pafi»w})  =  |_|{/<oko) 1  r  6  pati,o(m 

=  LJ{/f(0  I  £  €  path.(£)} 

and  this  shows  that: 

V*  :  ft{MOP0{£))  =  MOP, (£) 

Next  we  calculate: 

MOPo(i)  =  |J{/K0 1  ** 6  p**bo(£)} 

=  I  r e  Lj{Pati-^)  I  (t,t)  €  F}  U  {[  ]  \£  £  E}} 

=  I  1  €  Pati=(0,  (4*)  6  F}  U  {1 1  £  £  E}) 

=  (UM'llW*)  1  1  €  PatJ'<>(0}  I  (*'•*)  e  F})  U  4 

=  (\J{ft'(MOP0(£'))  |  (£',£)  £  F})  U  4 

Together  this  shows  that  ( MOP0 ,  MOP,)  is  a  solution  to  the  data  flow  equations. 
Using  Proposition  A. 10  of  Appendix  A  and  the  fact  that  (MFP0,  MFP,)  is  the  least 
solution  we  get  MOP0  3  MFP0  and  MOP,  3  MFP, .  Together  with  the  results  of 
the  first  part  of  the  lemma  we  get  MOP0  =  MFP0  and  MOP,  =  MFP,.  ■ 
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We  shall  leave  it  to  Exercise  2.13  to  show  that  the  condition  that  path0(C)  ^  0 
(for  i  in  E  and  F)  does  hold  when  the  Monotone  Framework  is  constructed 
from  a  program  5*  in  the  manner  of  the  earlier  sections. 

It  is  sometimes  stated  that  the  MOP  solution  is  the  desired  solution  and 
that  one  only  uses  the  MFP  solution  because  the  MOP  solution  might  not  be 
computable.  In  order  to  validate  this  we  would  need  to  prove  that  the  MOP 
solution  is  semantically  correct  as  was  proved  for  the  MFP  solution  in  Section 
2.2  in  the  case  of  Live  Variables  Analysis  -  in  the  case  of  Live  Variables  this 
is  of  course  immediate  since  it  is  a  Distributive  Framework.  However,  it  is 
always  possible  to  formulate  the  MOP  solution  as  an  MFP  solution  over  a 
different  property  space  (like  V{L))  and  therefore  little  is  lost  by  focusing  on 
the  fixed  point  approach  to  Monotone  Frameworks. 


2.5  Interprocedural  Analysis 

The  Data  Flow  Analysis  techniques  that  have  been  presented  in  the  previous 
sections  are  called  intraprocedural  analyses  because  they  deal  with  simple 
languages  without  functions  or  procedures.  It  is  somewhat  more  demand¬ 
ing  to  perform  interprocedural  analyses  where  functions  and  procedures  are 
taken  into  account.  Complications  arise  when  ensuring  that  calls  and  returns 
match  one  another,  when  dealing  with  parameter  mechanisms  (and  the  alias¬ 
ing  that  may  result  from  call-by-reference)  and  when  allowing  procedures  as 
parameters. 

In  this  section  we  shall  introduce  some  of  the  key  techniques  of  interproce¬ 
dural  analysis.  To  keep  things  simple  we  just  extend  the  WHILE  language 
with  top-level  declarations  of  global  mutually  recursive  procedures  having  a 
call-by-value  parameter  and  a  call-by-result  parameter.  The  extension  of  the 
techniques  to  a  language  where  procedures  may  have  multiple  call-by-value, 
call-by-result  and  call-by-value-result  parameters  is  straightforward  and  so  is 
the  extension  with  local  variable  declarations  (see  Exercise  2.20)  and  we  shall 
allow  to  use  these  extensions  in  examples. 

Syntax  of  the  procedure  language.  A  program,  P*,  in  the  ex¬ 
tended  WHILE-Ianguage  has  the  form 

begin  D*  5*  end 

where  D*  is  a  sequence  of  procedure  declarations: 

D  ::=  proc  p(val  a;,  res  y)  is<n  S  endfl  |  D  D 

Procedure  names  (denoted  p)  are  syntactically  distinct  from  variables  (de¬ 
noted  x  and  y).  The  label  ln  of  is  marks  the  entry  to  the  procedure  body 
and  the  label  lx  of  end  marks  the  exit  from  the  procedure  body.  The  syntax 
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of  statements  is  extended  with: 

5  |  [call  p(o,z)]£ 

The  call  statement  has  two  labels:  4  will  be  used  for  the  call  of  the  procedure 
and  4  will  be  used  for  the  associated  return;  the  actual  parameters  are  a  and 
z. 

The  language  is  statically  scoped,  the  parameter  mechanism  is  call-by-value 
for  the  first  parameter  and  call-by-result  for  the  second  parameter  and  the 
procedures  may  be  mutually  recursive.  We  shall  assume  throughout  that 
the  program  is  uniquely  labelled  (and  hence  label  consistent);  also  we  shall 
assume  that  only  procedures  that  have  been  declared  in  Z)*  are  ever  called 
and  that  D*  does  not  contain  two  definitions  of  the  same  procedure  name. 

Example  2.33  Consider  the  following  program  calculating  the  Fibonacci 
number  of  the  positive  integer  stored  in  x  and  returning  it  in  y: 

begin  proc  f  ib(val  z,  u,  res  v)  is1 

if  [z<3]2  then  [v:=u+l]3 

else  ([call  fib(z-l,u,v)]5;  [call  f  ib(z-2,v,v)]f) 

end8; 

[call  f  ib(x,0,y)]?0 

end 


It  uses  the  procedure  fib  that  returns  in  v  the  Fibonacci  number  of  z  plus 
the  value  of  u.  Both  x  and  y  are  global  variables  whereas  z,  u  and  v  are 
formal  parameters  and  hence  local  variables.  ■ 


Flow  graphs  for  statements.  The  next  step  is  to  extend  the  defi¬ 
nitions  of  the  functions  init,  final,  blocks,  labels,  and  Sow  to  specify  the  flow 
graphs  also  for  the  procedure  language.  For  the  new  statement  we  take: 


init([callp(o,z)]£)  = 
finaf([call  p(a,  z)]*‘)  = 

bfocks([call  p(a,  z)]l£ )  — 

labels([call  p(a,  z)]*')  = 

flow([call  p(a,z)]£)  = 


lc 

{4} 

{[call  p{a,z)}\l} 

{lc,lr} 

{(4;  4),  (4;  4)} 

if  proc  p(val  z,res  y)  is*n  5  end** 
is  in  £>* 


Here  (4;  4)  and  (4;  4)  are  new  kinds  of  flows: 

•  (4;  4)  is  the  flow  corresponding  to  calling  a  procedure  at  4  and  with 
4  being  the  entry  point  for  the  procedure  body,  and 
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•  (4;  4)  is  the  flow  corresponding  to  exiting  a  procedure  body  at  lx  and 
returning  to  the  call  at  4- 


The  definition  of  flow(  [call  p(a,z)]ltcr)  exploits  the  fact  that  the  syntax  of 
procedure  calls  only  allows  us  to  use  the  (constant)  name  of  a  procedure 
defined  in  the  program;  had  we  been  allowed  to  use  a  variable  that  denotes 
a  procedure  (e.g.  because  it  was  a  formal  parameter  to  some  procedure  or 
because  it  was  a  variable  being  assigned  some  procedure)  then  it  would  be 
much  harder  to  define  fiow([call  p(a,  z)]/')-  This  is  often  called  the  dynamic 
dispatch  problem  and  we  shall  deal  with  it  in  Chapter  3. 

Flow  graphs  for  programs.  Next  consider  the  program  P*  of  the 
form  begin  D*  5*  end.  For  each  procedure  declaration  proc  p(val  x,  res  y) 
is*n  S  end**  we  set 


init(p) 

Bnal{p) 

blocks(p) 

labels(p) 

Qow(p) 


{4} 

{is*n ,  end** }  U  blocks(S) 

{4,4}  U  la bels(S) 

{{in,init(S))}  U  flow(S)  U  {(fl,4)  1 1  £  final(S)} 


and  for  the  entire  program  P*  we  set 


init* 
final* 
blocks * 

labels* 

flow* 


=  init(Si') 

=  final(S*) 

=  l^J{b/odcs(p)  |  proc  p(val  x,  res  y)  is*"  S  end**  is  in  D*} 
U  blocks(S *) 

=  (^J{labels(p)  |  proc  p(val  x,res  y)  is*n  S  end**  is  in  D*} 
U  labels(S*) 

=  (J{flow(p)  |  proc  p(val  x,  res  y )  is*"  S  end**  is  in  £>*} 

U  fiow(5*) 


as  well  as  Lab*  =  labels *. 

We  shall  also  need  to  define  a  notion  of  interprocedural  flow 

inter-flow *  =  {(4, 4, 4, 4)  |  P*  contains  [call  p(a,  z)]ltc 

as  well  as  proc  p(val  x,res  y)  is*"  S  end**} 

that  clearly  indicates  the  relationship  between  the  labels  of  a  procedure  call 
and  the  corresponding  procedure  body. 
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proc  fib(val  z,  u,  res  v) 


Figure  2.7:  Flow  graph  for  the  Fibonacci  program. 


Example  2.34  For  the  Fibonacci  program  considered  in  Example  2.33 
we  have 


flow*  =  {(1,2),  (2, 3),  (3, 8), 

(2, 4),  (4;  1),  (8;  5),  (5,6),  (6;  1),  (8;  7),  (7, 8), 

(9;  1),  (8;  10)} 

inter-flow*  =  {(9, 1,8, 10),  (4, 1,8,5),  (6, 1,8,7)} 

and  init*  =  9  and  final*  =  {10}.  The  corresponding  flow  graph  is  illustrated 
in  Figure  2.7.  ■ 

For  a  forward  analysis  we  use  F  =  flow *,  E  =  {init*}  and  IF  =  inter-flow* 
whereas  for  a  backward  analysis  we  use  F  —  Sow E  =  final*  and  IF  = 
inter- flow*.  However,  the  explanations  in  the  sequel  will  focus  on  forward 
analyses. 

2.5.1  Structural  Operational  Semantics 

We  shall  now  show  how  the  semantics  of  While  can  be  extended  to  cope 
with  the  new  constructs.  To  ensure  that  the  language  allows  local  data  in 
procedures  we  shall  need  to  distinguish  between  the  values  assigned  to  dif¬ 
ferent  incarnations  of  the  same  variable  and  for  this  we  introduce  an  infinite 
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set  of  locations  (or  addresses): 

£  €  Loc  locations 

An  environment ,  p,  will  map  the  variables  in  the  current  scope  to  their  loca¬ 
tions,  and  a  store,  c,  will  then  specify  the  values  of  these  locations: 

p  £  Env  =  Var*  -4  Loc  environments 

C  €  Store  =  Loc  -4fin  Z  stores 

Here  Var*  is  the  (finite)  set  of  variables  occurring  in  the  program  and 
Loc  -*fin  Z  denotes  the  set  of  partial  functions  from  Loc  to  Z  that  have 
a  finite  domain.  Thus  the  previously  used  states  a  E  State  =  Var*  -4  Z 
have  been  replaced  by  the  two  mappings  p  and  c  and  can  be  reconstructed 
as  a  =  c  o  p:  to  determine  the  value  of  a  variable  x  we  first  determine  its 
location  f  =  p(x)  and  next  the  value  c(0  stored  in  that  location.  For  this 
to  work  it  is  essential  that  cop:  Var*  -4  Z  is  a  total  function  rather  than 
a  partial  function;  in  other  words,  we  demand  that  ran(p)  C  dom(c)  where 
ran(p)  =  {p(x)  |  x  €  Var*}  and  dom( c)  =  {£  |  c  is  defined  on  £}. 

The  locations  of  the  global  variables  of  the  program  P*  are  given  by  a  top-level 
environment  denoted  p*;  we  shall  assume  that  it  maps  all  variables  to  unique 
locations.  The  semantics  of  statements  is  now  given  relative  to  modifications 
of  this  environment.  The  transitions  have  the  general  form 

PK  (S,c)  ->  <S',c'> 

in  case  that  the  computation  does  not  terminate  in  one  step,  and  the  form 

ph*  (S,  c)  -4  C; 

in  case  that  it  does  terminate  in  one  step.  It  is  fairly  straightforward  to 
rewrite  the  semantics  of  While  given  in  Table  2.6  to  have  this  form;  as  an 
example  the  clause  [ass]  for  assignments  becomes: 

p  h*  (x:=a,c)  -4  c[p(x)  ►-*  -4[aJ(c  o  p)]  if  c  o  p  is  total 

Note  that  there  is  no  need  to  modify  the  semantics  of  arithmetic  and  boolean 
expressions. 

For  procedure  calls  we  make  use  of  the  top-level  environment,  p*,  and  we 
take: 

ph*  ([callp(a,z)]£,c>  -> 

(bind  p*[x  1-4  £i,j/ 1-4  &]  in  S  then  z:=y, c[£i  H-  A[a](c°p),6  *-*■  «]) 

where  t  dom(p),v  E  Z 

and  proc  p(val  x,res  y)  is^"  S  end^1  is  in  £>* 

The  idea  is  that  we  allocate  new  locations  fy  and  fy  for  the  formal  parameters 
x  and  y,  and  we  then  make  use  of  a  bind -construct  to  combine  the  procedure 
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body  5  with  the  environment  p*[x  £i,y  £2]  in  which  it  must  be  executed 
and  we  also  record  that  the  final  value  of  y  must  be  returned  in  the  actual 
parameter  z.  At  the  same  time  the  store  is  updated  such  that  the  new 
location  for  x  is  mapped  to  the  value  of  the  actual  parameter  a  whereas  we 
do  not  control  the  initial  value  of  the  new  location  for  y.  The  bind-construct 
is  only  needed  to  ensure  that  we  have  static  scope  rules  and  its  semantics  is 
as  follows: 

_ P1  K  (S,c)  ->  (5>,Q _ 

p  K  (bind  p'  in  5  then  z:=y,<r)  ->  (bind  p'  in  S'  then  z:=y,q') 

_ p'  b*  (S,  Q  ->  _ 

p  h*  (bind  p‘  in  5  then  z:=y,<;)  -t  <;'[p(z)  i->  <r'(p'(j/))] 

The  first  rule  expresses  that  executing  one  step  of  the  body  of  the  construct 
amounts  to  executing  one  step  of  the  construct  itself;  note  that  we  use  the 
local  environment  when  executing  the  body.  The  second  rule  expresses  that 
when  the  execution  of  the  body  finishes  then  so  does  execution  of  the  con¬ 
struct  itself  and  we  update  the  value  of  the  global  variable  z  to  be  that  of  the 
local  variable  y;  furthermore,  there  is  no  need  for  the  local  environment  p'  to 
be  retained  as  subsequent  computations  will  use  the  previous  environment  p. 

Remark.  Although  the  semantics  works  with  two  mappings,  an  environ¬ 
ment  and  a  store,  it  is  often  the  case  that  the  analysis  abstracts  the  state, 
i.e.  the  composition  of  the  environment  and  the  store.  The  correctness  of  the 
analysis  will  then  have  to  relate  the  abstract  state  both  to  the  environment 
and  the  store. 

The  correctness  result  will  often  be  expressed  in  the  style  of  Section  2.2: 
information  obtained  by  analysing  the  original  program  will  remain  correct 
under  execution  of  the  program.  The  semantics  presented  above  deviates 
from  that  of  the  WHILE-Ianguage  in  that  it  introduces  the  bind-construct 
which  is  only  used  in  the  intermediate  configurations.  So  in  order  to  prove 
the  correctness  result  we  will  also  need  to  specify  how  to  analyse  the  bind- 
construct.  We  refer  to  Chapter  3  for  an  illustration  of  how  to  do  this.  ■ 

2.5.2  Intraprocedural  versus  Interprocedural  Analysis 

To  appreciate  why  interprocedural  analysis  is  harder  than  intraprocedural 
analysis  let  us  begin  by  just  naively  using  the  techniques  from  the  previous 
sections.  For  this  we  suppose  that: 

•  for  each  procedure  call  [call  p(a ,  z)]*'  we  have  two  transfer  functions 
f(c  and  ftr  corresponding  to  calling  the  procedure  and  returning  from 
the  call,  and 

•  for  each  procedure  definition  proc  p(val  2;,  res  y)  is*n  S  end**  we 
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have  two  transfer  functions  /<„  and  fix  corresponding  to  entering  and 
exiting  the  procedure  body. 


A  naive  formulation.  Given  an  instance  (L,  T,  F,  E,  t,  /.)  of  a  Mono¬ 
tone  Framework  we  shall  now  treat  the  two  kinds  of  flow  ((4,4)  versus 
(£c;£n)  and  (4;  4))  *n  the  same  way:  we  interpret  the  semi-colon  as  stand¬ 
ing  for  a  comma.  While  a  Monotone  Framework  is  allowed  to  interpret  all 
transfer  functions  freely,  we  shall  for  now,  naively,  assume  that  the  two  trans¬ 
fer  functions  associated  with  procedure  definitions  are  the  identity  functions, 
and  that  the  two  transfer  functions  associated  with  each  procedure  call  are 
also  the  identity  functions,  thus  effectively  ignoring  the  parameter-passing. 

We  now  obtain  an  equation  system  of  the  form  considered  in  the  previous 
sections: 


A.(£)  =  h{A0{£)) 

A0{£)  =  \_\{A.{£')\  {£',£)  e  F  or  {£'-,£)eF}vnlE 

Here  tlE  is  as  in  Section  2.3: 

i  _ j  i  if  f  6  £ 

Le  ~  {  X  if  £  i  E 

When  inspecting  this  equation  system  is  should  be  apparent  that  both  proce¬ 
dure  calls  (4;  4.)  and  procedure  returns  (4;  4)  are  treated  like  goto’s:  there 
is  no  mechanism  for  ensuring  that  information  flowing  along  (4;4»)  from  a 
call  to  a  procedure  only  flows  back  along  (4;  4)  from  the  procedure  to  the 
same  call.  (Indeed,  nowhere  does  the  formulation  consult  the  interprocedu¬ 
ral  flow,  IF.)  Expressed  in  terms  of  the  flow  graph  in  Figure  2.7,  there  is 
nothing  preventing  us  from  considering  a  path  like  [9, 1, 2, 4, 1, 2, 3, 8, 10]  that 
does  not  correspond  to  a  run  of  the  program.  Intuitively,  the  equation  system 
considers  a  much  too  large  set  of  “paths”  through  the  program  and  hence 
will  be  grossly  imprecise  (although  formally  on  the  safe  side). 

Valid  paths.  A  natural  way  to  overcome  this  shortcoming  is  to  somehow 
restrict  the  attention  to  paths  that  have  the  proper  nesting  of  procedure  calls 
and  exits.  We  shall  explore  this  idea  in  the  context  of  redefining  the  MOP 
solution  of  Section  2.4  to  only  take  the  proper  set  of  paths  into  account, 
thereby  defining  an  MVP  solution  (for  Meet  over  all  Valid  Paths). 

So  consider  a  program  P*  of  the  form  begin  D*  5*-  end.  A  path  is  said  to  be 
a  complete  path  from  4  to  4  in  P*  if  it  is  has  proper  nesting  of  procedure 
entries  and  exits  and  such  that  a  procedure  returns  to  the  point  where  it  was 
called.  These  paths  are  generated  by  the  nonterminal  CPtlte2  according  to 
the  following  productions: 
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CPeltt 2  — >  4  whenever  4  =  4 

CPiui 3  — »  4,  whenever  (4,4)  G  F; 

for  a  forward  analysis  this  means 
that  (£1,(2)  £  flow* 

CPtc ,/  — >4,  CPtn ,  CP tr,t  whenever  (4 ,4,4,4)  €  IF; 

for  a  forward  analysis  this  means 
that  F*  contains  [call  p(o,  2)]** 
and  proc  p(val  x,  res  y)  is*"  S  end*1 

The  matching  of  calls  and  returns  is  ensured  by  the  last  kind  of  productions: 
the  flows  (4;  4)  and  (4;  4)  are  forced  to  obey  a  parenthesis  structure  in 
that  4,4  only  will  be  in  the  generated  path  if  there  is  a  matching  occur¬ 
rence  of  4,4  -  and  vice  versa.  Hence  for  a  forward  analysis,  a  terminating 
computation  will  give  rise  to  a  complete  path  from  init*  to  one  of  the  labels 
of  final*.  Note  that  the  grammar  constructed  above  will  only  have  a  finite 
set  of  nonterminals  because  there  only  is  a  finite  set  of  labels  in  P*. 

Example  2.35  For  the  Fibonacci  program  of  Example  2.33  we  obtain  the 
following  grammar  (using  forward  flow  and  ignoring  the  parts  not  reachable 
from  CP9)  10): 

CPg.JO  *  9,  CPi,8,  CPio.10  CP 3,8  — >  3,  CPs, 8 

CP1040  — y  10  -  CPs, 8  — y  8 

CPi, 8  — >  l,CP2i8  -  CP4, 8  — ►  4,  CP!, g,  CP5, 8 

Cp2,8  y  2,  CP3,8  CP5,8  y  5,  CPe,8 

CP2, 8  — y  2,  CP4]8  CPe, 8  — y  6,  CPi,8,  CP7,8 

CPt,8  — y  7,  CPs ,8 

It  is  now  easy  to  verify  that  the  path  [9, 1, 2, 4, 1, 2, 3, 8, 5, 6, 1, 2, 3, 8, 7, 8, 10] 
is  generated  by  CP9, 10  whereas  the  path  [9, 1, 2, 4, 1, 2, 3, 8, 10]  is  not.  ■ 

A  path  is  said  to  be  a  valid  path  if  it  starts  at  an  extremal  node  of  P*  and 
if  all  the  procedure  exits  match  the  procedure  entries  but  it  is  possible  that 
some  procedures  are  entered  but  not  yet  exited.  This  will  obviously  include 
all  prefixes  of  the  complete  paths  starting  in  E  but  we  also  have  to  take  into 
account  prefixes  of  computations  that  might  not  terminate.  To  specify  the 
valid  paths  we  therefore  construct  another  grammar  with  productions: 


VP*  — y 

VP(l,t* 

whenever  4  G  E  and  £2  G  Lab. 

§ 

"c* 

to 

- »  tl 

whenever  4=4 

VPtut3  ■ 

— y  4,  vpt2,l3 

whenever  (4,4)  £  F 

VPeC}t  - 

->  4,  CPinttt,  VP(rit 

whenever  (4, 4, 4, 4)  £  IF 

VPtc,t  - 

-*  4,  VPln<l 

whenever  (4, 4, 4, 4)  £  IF 
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The  valid  paths  will  then  be  generated  by  the  nonterminal  VP*.  For  a  for¬ 
ward  analysis,  to  come  from  the  label  £c  of  a  procedure  call  to  the  program 
point  £  there  are  two  possibilities.  One  is  that  the  call  initiated  at  £e  ter¬ 
minates  before  reaching  £  and  this  corresponds  to  the  second  last  kind  of 
production  where  we  use  the  nonterminal  CP(nitx  to  generate  the  complete 
path  corresponding  to  executing  the  procedure  body.  The  other  possibility  is 
that  £  is  reached  before  the  call  terminates  and  this  corresponds  to  the  last 
kind  of  production  where  we  simply  use  VPtn,t  to  generate  a  valid  path  in 
the  procedure  body. 

We  can  now  modify  the  two  sets  of  paths  defined  in  Section  2.3  as  follows 
(keeping  in  mind  that  the  definitions  are  implicitly  parameterised  on  F,  E 
and  IF)  : 

vpath0(£ )  =  {[fy,  ■  •  •  ,£n-i]  |  n  >  1  A  tn  =  £  A  [£\,  •  •  •  ,ln]  is  a  valid  path} 

vpath,(£)  =  {[fy,  ■  •  • ,  £n]  |  n  >  1  A  £n  =  £  A  [fy,  •••,£„]  is  a  valid  path} 

Clearly  the  sets  of  paths  are  smaller  than  what  would  have  resulted  if  we 
had  merely  regarded  as  standing  for  (fy,fy)  and  had  used  the  notions 

path0{£ )  and  patht{£)  of  Section  2.3. 

Using  valid  paths  we  now  define  the  MVP  solution  as  follows: 

MVP0(£)  =  l_|{£<0  1 1 €  vpath0(£)} 

MVP . (£)  =  \JUfr)  |  £  e  vpath.(£)} 

Since  the  sets  of  paths  are  smaller  than  in  the  similar  definitions  in  Section 
2.3,  we  clearly  have  MVP0(£)  C  MOP0(£ )  and  MVP.(£)  C  MOP.(£ )  for  all 
£. 


2.5.3  Making  Context  Explicit 

The  MVP  solution  may  be  undecidable  for  lattices  of  finite  height,  just  as  was 
the  case  for  the  MOP  solution,  so  we  now  have  to  reconsider  the  MFP  solution 
and  how  to  avoid  taking  too  many  invalid  paths.  An  obvious  approach  is 
to  encode  information  about  the  paths  taken  into  the  data  flow  properties 
themselves;  to  this  end  we  introduce  context  information: 

5  €  A  context  information 

The  context  may  simply  be  an  encoding  of  the  path  taken  but  we  shall  see 
in  Subsection  2.5.5  that  there  are  other  possibilities.  We  shall  now  show  how 
an  instance  of  a  Monotone  Framework  (as  introduced  in  Section  2.3)  can  be 
extended  to  take  context  into  account. 
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The  intraprocedural  fragment.  Consider  an  instance  (L,  F,  F,  E, 
«.,/.)  of  a  Monotone  Framework.  We  shall  now  construct  an  instance 

(■ L,F,F,E,?J. ) 

of  an  embellished  monotone  framework  that  takes  context  into  account.  We 
begin  with  the  parts  of  its  definition  that  are  independent  of  the  actual  choice 
of  A,  i.e.  the  parts  that  correspond  to  the  intraprocedural  analysis: 

•  L  —  A  — y  L\ 

•  the  transfer  functions  in  F  are  monotone;  and 

•  each  transfer  function  ft  is  given  by  ft  (l  )(<5)  =  ft(l  (5)). 

In  other  words,  the  new  instance  applies  the  transfer  functions  of  the  original 
instance  in  a  pointwise  fashion. 

Ignoring  procedures,  the  data  flow  equations  will  take  the  form  displayed 
earlier: 

A.(£)  =  Tt{A0{i)) 

for  all  labels  that  do  not  label  a  procedure  call 
(i.e.  that  do  not  occur  as  first  or  fourth  components 
of  a  tuple  in  IF)  , 

Aa{i)  =  \J{A.(£')\  (£',£)€  For  (£'■,£)  €F}U^ 

for  all  labels  (including  those  that  label  procedure  calls) 

Example  2.36  Let  (Lsjgn ,  ^"sign ,  F,  E,  tSign  ,  /s'gn)  be  an  instance  of  a  Mono¬ 
tone  Framework  specifying  a  Detection  of  Signs  Analysis  (see  Exercise  2.15) 
and  assume  that 

■I'sign  =  'PCVar*  -y  Sign) 

where  Sign  =  {-,  0,  +}.  Thus  Lsign  describes  sets  of  abstract  states  oSLgn  map¬ 
ping  variables  to  their  possible  signs.  The  transfer  function  associated 
with  the  assignment  [x  :=  a]*  will  now  be  written  as 

fi'e"{Y)  =  U{<$gVign)  |  (7sign  £  Y) 

where  Y  C  Var*  — >  Sign  and 

^ign(asign)  =  {<rsign[x  s]  |  s  6  Aignla](<75ign)} 

Here  As ign  :  AExp  — >  (Var*  ->  Sign)  ->  "P(Sign)  specifies  the  analysis  of 
arithmetic  expressions.  The  transfer  functions  for  tests  and  skip-statements 
are  the  identity  functions. 
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Given  a  set  A  of  contexts,  the  embellished  monotone  framework  will  have 

f-sign  =  A  — ^  isign 

but  we  shall  prefer  the  following  isomorphic  definition 
£sign  =  V(A  x  (Var*  ->  Sign)) 

Thus  LSign  describes  sets  of  pairs  of  context  and  abstract  states.  The  transfer 
function  associated  with  the  assignment  [x  :=  a]*  will  now  be: 

fFn  (Z)  =  U(W  X  $gVgn)  I  (<^sign)  6  Z} 

In  subsequent  examples  we  shall  further  develop  this  analysis.  ■ 

The  interprocedural  fragment.  It  remains  to  formulate  the  data 
flow  equations  corresponding  to  procedures. 

For  a  procedure  definition  proc  p(val  x ,  res  y)  is*"  S  end**  we  have  two 
transfer  functions: 


fu  ,fix  :  (A  L)  -*  (A  ->  L) 

In  the  case  of  our  simple  language  we  shall  prefer  to  take  both  of  these  transfer 
functions  to  be  the  identity  function;  i.e. 

TUO  =  T 
VA T)  =  T 

for  all  l  e  L .  Hence  the  effect  of  procedure  entry  is  handled  by  the  trans¬ 
fer  function  for  procedure  call  (considered  below)  and  similarly  the  effect  of 
procedure  exit  is  handled  by  the  transfer  function  for  procedure  return  (also 
considered  below).  For  more  advanced  languages  where  many  semantic  ac¬ 
tions  take  place  at  procedure  entry  or  exit  it  may  be  preferable  to  reconsider 
this  decision. 

For  a  procedure  call  (£c,  £n,  £x,£r)  €  IF  we  shall  define  two  transfer  functions. 
In  our  explanation  we  shall  concentrate  on  the  case  of  forward  analyses  where 
P*  contains  [call  p(a,  z)]*'  as  well  as  proc  p(val  x, res  y)  is*"  5  end**. 
Corresponding  to  the  actual  call  we  have  the  transfer  function 

fl  :  (A  ->  L)  -+  (A  ->  L) 

and  it  is  used  in  the  equation: 

A.(£c)  =  fl  {A0{tc))  forall(4A,4,C)eIF 
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proc  p(val  a:,  res  y) 


Figure  2.8:  Analysis  of  procedure  call:  the  forward  case. 


In  other  words,  the  transfer  function  modifies  the  data  flow  properties  (and 
the  context)  as  required  for  passing  to  the  procedure  entry. 

Corresponding  to  the  return  we  have  the  transfer  function 

f£ir  :  (A  ->  L)  x  (A  ->  L)  -4  (A  ->  L) 
and  it  is  used  in  the  equation: 

A.(er)  =  fl}r(Ao(ec);Ao(er))  foraii  (ec,en,ex,er)  eiF 

The  first  parameter  of  ft  tr  describes  the  data  flow  properties  at  the  call 
point  for  the  procedure  and  the  second  parameter  describes  the  properties  at 
the  exit  from  the  procedure  body.  Ignoring  the  first  parameter,  the  transfer 
function  modifies  the  data  flow  properties  (and  the  context)  as  required  for 
passing  back  from  the  procedure  exit.  The  purpose  of  the  first  parameter  is 
to  recover  some  of  the  information  (data  flow  properties  as  well  as  context 
information)  that  was  available  before  the  actual  call;  how  this  is  done  de¬ 
pends  on  the  actual  choice  of  the  set,  A,  of  context  information  and  we  shall 
return  to  this  shortly.  Figure  2.8  illustrates  the  flow  of  data  in  the  analysis 
of  the  procedure  call. 

Variations.  The  functionality  and  use  of  ft  tr  (as  well  as  Figure  2.8)  is 
sufficiently  general  that  it  allows  us  to  deal  with  most  of  the  scenarios  found 
in  the  literature.  A  simple  example  being  the  possibility  to  define 

thereby  completely  ignoring  the  information  before  the  call;  this  is  illustrated 
in  Figure  2.9. 
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proc  p(val  x,res  y) 


Figure  2.9:  Analysis  of  procedure  call:  ignoring  calling  context. 


proc  p(val  x,  res  y) 


Figure  2.10:  Analysis  of  procedure  call:  merging  of  context. 

A  somewhat  more  interesting  example  is  the  ability  to  define 

thereby  allowing  a  simple  combination  of  the  information  coming  back  from 
the  call  with  the  information  pertaining  before  the  call.  This  form  is  illus¬ 
trated  in  Figure  2.10  and  is  often  mot;vated  on  the  grounds  that  f\^lr  copies 
data  that  is  local  to  the  calling  procedure  whereas  copies  information 

that  is  global.  (It  may  be  worth  noticing  that  the  function  ff  tr  is  com¬ 
pletely  additive  if  and  only  if  it  can  be  written  in  this  form  with  fj^tr  and 
fiftr  being  completely  additive.) 
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Context-sensitive  versus  context-insensitive.  So  fax  we  have 
criticised  the  naive  approach  because  it  was  unable  to  maintain  the  proper 
relationship  between  procedure  calls  and  procedure  returns.  A  related  criti¬ 
cism  of  the  naive  approach  is  that  it  cannot  distinguish  between  the  different 
calls  of  a  procedure.  The  information  about  calling  states  is  combined  for 
all  call  sites,  the  procedure  body  is  analysed  only  once  using  this  combined 
information,  and  the  resulting  information  about  the  set  of  return  states  is 
used  at  all  return  points.  The  phrase  context-insensitive  is  often  used  to  refer 
to  this  shortcoming. 

The  use  of  non-trivial  context  information  not  only  helps  to  avoid  the  first 
criticism  but  also  the  second:  if  there  are  two  different  calls  but  they  are 
reached  with  different  contexts,  <5i  and  82,  then  all  information  obtained  from 
the  procedure  will  be  clearly  related  to  <5i  or  82  and  no  undesired  combination 
or  “cross-over”  will  take  place.  The  phrase  context-sensitive  is  often  used  to 
refer  to  this  ability. 

Clearly  a  context-sensitive  analysis  is  more  precise  than  a  context-insensitive 
analysis  but  at  the  same  time  it  is  also  likely  to  be  more  costly.  The  choice  be¬ 
tween  which  technique  to  use  amounts  to  a  careful  balance  between  precision 
and  efficiency. 


2.5.4  Call  Strings  as  Context 

To  complete  the  design  of  the  analysis  of  the  program  we  must  choose  the  set, 
A,  of  context  information  and  also  specify  the  extremal  value,  T ,  and  define 
the  two  transfer  functions  associated  with  procedure  calls.  In  this  subsection 
we  shall  consider  two  approaches  based  on  call  strings  and  our  explanation 
will  be  in  terms  of  forward  analyses. 

Call  strings  of  unbounded  length.  As  the  first  possibility  we 
simply  encode  the  path  taken;  however,  since  our  main  interest  is  with  pro¬ 
cedure  calls  we  shall  only  record  flows  of  the  form  (Cc',tn)  corresponding  to 
a  procedure  call.  Formally  we  take 

A  =  Lab* 

where  the  most  recent  label  tc  of  a  procedure  call  is  at  the  right  end  (just  as 
was  the  case  for  valid  paths  and  paths);  elements  of  A  are  called  call  strings. 
We  then  define 

T  =  (A,  1) 

where  A  is  the  empty  sequence  corresponding  to  the  fact  that  there  are  no 
pending  procedure  calls  when  the  program  starts  execution;  t  is  the  extremal 
value  available  from  the  underlying  Monotone  Framework. 
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Example  2.37  For  the  Fibonacci  program  of  Example  2.33  the  following 
call  strings  will  be  of  interest: 

A,  [9],  [9, 4],  [9, 6],  [9, 4, 4],  [9, 4, 6],  [9, 6, 4],  [9, 6,6],  -  -- 

corresponding  to  the  cases  with  0, 1, 2, 3,  •  ■  •  pending  procedure  calls.  ■ 

For  a  procedure  call  (tc,£n,tx,tr)  €  IF,  amounting  to  [call  p(ay  in 

the  case  of  a  forward  analysis,  we  define  the  transfer  function  such  that 

f}e  0  )([<$>  £c])  =  f}c(l  (<$))  where  [J,  tc]  denotes  the  path  obtained  by  append¬ 
ing  Ic  to  8  (so  as  to  reflect  that  now  we  enter  the  body  of  the  procedure) 
and  the  function  :  L  -»  L  describes  how  the  property  is  modified.  This  is 
achieved  by  setting 

7 T  m/m  _  /  fic  (1(6))  when  S'  =  [8,  Q 
±  otherwise 

which  takes  care  of  the  special  case  of  empty  paths. 

Next  we  define  the  transfer  function  f\  tr  corresponding  to  returning  from 
the  procedure  call: 

fl^r(T,P)(6)  =  fllr(T(S),P({s,ec})) 

Here  the  information  l  from  the  original  call  is  combined  with  information  l1 
from  the  procedure  exit  using  the  function  f}c  lr  :  L  x  L  ->  L.  However,  only 
information  corresponding  to  the  same  contexts  for  call  point  tc  is  combined: 
this  is  ensured  by  the  two  occurrences  of  8  in  the  above  formula. 

Example  2.38  Let  us  return  to  the  Detection  of  Signs  Analysis  of  Ex¬ 
ample  2.36.  For  a  procedure  call  [call  p(a,  z)]*'  where  p  is  declared  by 
proc  p(val  x,  res  y)  is*n  S  end*1  we  may  take: 

/p  (Z)  =  U  {{S'}  X  48"V«")  I  (<*>"«")  eZ  A  8'  =  [8,ec]} 

<gnVig")  =  {o**[x  S}[y  H-  s']  I  s  €  AignlaK^*")  A  s'  £  {-,0,+}} 

When  returning  from  the  procedure  call  we  take: 

fSl(z>z')  =  U{Wx€!K"^ign)i(^n^A 

A  (S',a**n)  EZ'  A  S' =  (S,£c\} 

Thus  we  extract  all  the  information  from  the  procedure  body  except  for  the 
information  about  the  formal  parameters  x  and  y  and  the  actual  parameter 
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2.  For  the  formal  parameters  we  rely  on  the  information  available  before  the 
current  call  which  is  still  correct  and  for  the  actual  parameter  we  perform  the 
required  update  of  the  information.  Note  that  to  facilitate  this  definition  it 
is  crucial  that  the  transfer  function  ff  t  takes  two  arguments:  information 
from  the  call  point  as  well  as  from  the  procedure  exit.  ■ 

Call  strings  of  bounded  length.  Clearly  the  call  strings  can  be¬ 
come  arbitrarily  long  because  the  procedures  may  be  recursive.  It  is  therefore 
customary  to  restrict  their  length  to  be  at  most  k  for  some  number  k  >  0; 
the  idea  being  that  only  the  last  k  calls  are  recorded.  We  write  this  as 

A  = Lab-fc 

and  we  still  take  the  extremal  value  to  be  T  =  (A,  t).  Note  that  in  the  case 
A;  =  0  we  have  A  =  {A}  which  is  equivalent  to  having  no  context  information. 

Example  2.39  Consider  the  Fibonacci  program  of  Example  2.33  and  as¬ 
sume  that  we  are  only  interested  in  recording  the  last  call,  i.e.  k  =  1.  Then 
the  call  strings  of  interest  are: 

A,  [9],  [4],  [6] 

Alternatively,  we  may  choose  to  record  the  last  two  calls,  i.e.  k  =  2,  in  which 
case  the  following  call  strings  are  of  interest: 

A,  [9],  [9, 4],  [9, 6]-, -[4, 4],  [4, 6],  [6, 4],  [6, 6] 

In  general,  we  would  expect  an  analysis  using  these  8  contexts  to  be  more 
precise  than  one  using  the  4  different  contexts  displayed  above.  ■ 

We  shall  now  present  the  transfer  functions  for  the  general  case  where  call 
strings  have  length  at  most  k.  The  transfer  function  f\  for  procedure  call 
is  redefined  by 

^(0(<j')=U{//cra)i<j'  =  r<5.4ifc} 

where  [5,41*  denotes  the  call  string  [5,  4]  but  possibly  truncated  (by  omit¬ 
ting  elements  on  the  left)  so  as  to  have  length  at  most  k.  Since  the  function 
mapping  5  to  [5,41*  >s  not  injective  (unlike  the  one  mapping  5  to  [5,4])  we 
need  to  take  the  least  upper  bound  over  all  5  that  can  be  mapped  to  the 
relevant  context  S'. 

Similarly,  the  transfer  function  fj  tr  for  procedure  return  is  redefined  by 
fVtr(T>n=fltrmS(\Wk)) 


as  should  be  expected. 
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Example  2.40  Let  us  consider  Detection  of  Signs  Analysis  in  the  special 
case  where  k  =  0,  i.e.  where  A  =  {A}  and  hence  A  x  (Var*  -¥  Sign)  is 
isomorphic  to  Var*  -¥  Sign.  Using  this  isomorphism  the  formulae  defining 
the  transfer  functions  for  procedure  call  can  be  simplified  to 

/?■  (Y)  =  uk“"V'‘"s  i  »”in  e  y) 

where  Y,  Y1  C  Var*  Sign.  It  is  now  easy  to  see  that  the  analysis  is  context- 
insensitive:  at  procedure  return  it  is  not  possible  to  distinguish  between  the 
different  call  points. 

Let  us  next  consider  the  case  where  k  =  1.  Here  A  =  Lab  U  {A}  and  the 
transfer  functions  for  procedure  call  are: 

/?‘(Z)  =  UfW  y  $TV!")  I  W**")  = 

/K(z.z')  = 

A  (4,4lgn)  e  z') 

Now  the  transfer  function  /^gnl  will  mark  all  data  from  the  call  point  ic  with 

that  label.  Thus  it  does  not  harm'ihat  the  information  /£gnl  (Z)  is  merged 

with  similar  information  /*gnl  (Z)  from  another  procedure  call.  At  the  return 

from  the  call  the  transfer  function  selects  those  pairs  (£c, of8")  €  Z' 

that  are  relevant  for  the  current  call  and  combines  them  with  those  pairs 
(<5,<7i'gn)  G  Z  that  describe  the  situation  before  the  call;  in  particular,  this 
allows  us  to  reset  the  context  to  be  that  of  the  call  point.  ■ 

2.5.5  Assumption  Sets  as  Context 

An  alternative  to  describing  a  path  directly  in  terms  of  the  calls  being  per¬ 
formed  is  to  record  information  about  the  state  in  which  the  call  was  made; 
these  methods  can  clearly  be  combined  but  in  the  interest  of  simplicity  we 
shall  abstain  from  doing  so. 

Large  assumption  sets.  Throughout  this  subsection  we  shall  make 
the  simplifying  assumption  that 

L  =  V{D) 

as  is  the  case  for  the  Detection  of  Signs  Analysis.  Restricting  the  attention 
to  only  recording  information  about  the  last  call  (corresponding  to  taking 
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k  =  1  above),  one  possibility  is  to  take 

A  =  V(D) 

and  we  then  take  the  extremal  value  to  be 

*  =  ({4.0 

meaning  that  the  initial  context  is  described  by  the  initial  abstract  state.  This 
kind  of  context  information  is  often  called  an  assumption  set  and  expresses 
a  dependency  on  data  (as  opposed  to  a  dependency  on  control  as  in  the  case 
of  call  strings). 

Example  2.41  Assume  that  we  want  to  perform  a  Detection  of  Signs 
Analysis  (Example  2.36)  of  the  Fibonacci  program  of  Example  2.33  and  that 
the  extremal  value  tSign  is  the  singleton  [x  4  +,y  ^  -,z  4  -].  Then  the 
contexts  of  primary  interest  will  be  sets  consisting  of  some  of  the  following 
abstract  states 

[x*-*+,yi->0,z  •->-],  [xi->+,yH4  0,zH>0],  [ih>+,y4  0,zi->+], 
[m+.yH+.zH-],  [xi4+,y4+,z4  0],  [xHt,yH+,zH+j 

corresponding  to  the  states  in  which  the  call-statements  may  be  encoun¬ 
tered.  ■ 

For  a  procedure  call  (tc,£n,tx,£r)  €  IF,  i.e.  [call  p(a,  z)]£  in  the  case  of 
forward  analysis,  we  define  the  transfer  function  //  for  procedure  call  by: 

f}c(Z)  =  \J{{8'}x4>l(d)\  (S,d)EZ  a 

S'  =  {d"  |  (M")  e  z}} 

where  <f>\  :D->  V(D).  The  idea  is  as  follows:  a  pair  (S,d)  E  Z  describes  a 
context  and  an  abstract  state  for  the  current  call.  We  now  have  to  modify 
the  context  to  take  the  call  into  account,  i.e.  we  have  to  determine  the  set  of 
possible  abstract  states  in  which  the  call  could  happen  in  the  current  context 
and  this  is  S'  =  {d"  |  ( S,d ")  E  Z}.  Given  this  context  we  proceed  as  in 
the  call  string  formulations  presented  above  and  mark  the  data  flow  property 
with  this  context. 

Next  we  shall  consider  the  transfer  function  fj  ^  for  procedure  return 

f£ir  =  IKW  x  I  (S',d')  E  Z'A 

S'  =  [d"\(S,d")  E  Z}} 

where  4%eitr  ■  D  x  D  ->  V(D).  Here  (S,d)  €  Z  describes  the  situation 
before  the  call  and  (S',  d')  E  Z'  describes  the  situation  at  the  procedure  exit. 
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From  the  definition  of  /£  we  know  that  the  context  matching  ((5,  d)  will  be 
S'  =  {d"  |  ( S,d ")  €  Z}  so  we  impose  that  condition.  We  can  now  combine 
information  from  before  the  call  with  that  at  the  procedure  exit  much  as  in 
the  call  string  approach;  in  particular,  we  can  reset  the  context  to  be  that  of 
the  call  point. 

Small  assumption  sets.  As  a  simpler  version  of  using  assumption 
sets  one  may  take 

A  =  D 

and  then  use  T  =  (i,  l)  as  the  extremal  value.  So  rather  than  basing  the 
embellished  monotone  framework  on  V{D)  x  D  as  above  we  now  base  it  on 
D  x  D.  Of  course,  this  is  much  less  precise  but,  on  the  positive  side,  the  size 
of  the  data  flow  properties  has  been  reduced  dramatically. 

For  a  procedure  call  {(.c,ln,tx,tT)  €  IF,  i.e.  [call  p(a,z)}((‘  for  forward  anal¬ 
yses,  the  transfer  function  /£  is  now  defined  by 

f}c(Z)  =  \J{{d}x<i>l(d)\(s,d)ez} 

where,  as  before,  <j>\c  :  D  -»  V(D).  Here  the  individual  pieces  of  information 
concerning  the  abstract  state  of  the  call  have  their  own  local  contexts;  we 
have  no  way  of  grouping  the  abstract  states  corresponding  to  S  as  we  did  in 
the  approach  with  large  assumption  sets. 

The  corresponding  definition  of  the  transfer  function  t  for  procedure 
return  then  is 

fV,  ^ z ')  =  U«*>  *  I  (M)  €  z  A  (d,d')  e  z'} 

where  again  </>?_.  :  D  x  D  — »  V{D).  Examples  of  how  to  use  assumption 

sets  will  be  considered  in  the  exercises. 


2.5.6  Flow-Sensitivity  versus  Flow-Insensitivity 

All  of  the  data  flow  analyses  we  have  considered  so  far  have  been  flow- 
sensitive:  this  just  means  that  in  general  we  would  expect  the  analysis  of 
a  program  Si;  52  to  differ  from  the  analysis  of  the  program  S2;  Si  where  the 
statements  come  in  a  different  order. 

Sometimes  one  considers  flow-insensitive  analyses  where  the  order  of  state¬ 
ments  is  of  no  importance  for  the  analysis  being  performed.  This  may  sound 
weird  at  first,  but  suppose  that  the  analysis  being  performed  is  like  the  ones 
considered  in  Section  2.1  except  that  for  simplicity  all  kill  components  are 
empty  sets.  Given  these  assumptions  one  might  expect  that  the  programs 
Si;S2  and  S2;Si  give  rise  to  the  same  analysis.  Clearly  a  flow-insensitive 
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analysis  may  be  much  less  precise  than  its  flow-sensitive  analogue  but  also  it 
is  likely  to  be  much  cheaper;  since  interprocedural  data  flow  analyses  tend 
to  be  very  costly,  it  is  therefore  useful  to  have  a  repertoire  of  techniques  for 
reducing  the  cost. 

Sets  of  assigned  variables.  We  shall  now  present  an  example  of  a 
flow-insensitive  analysis.  Consider  a  program  P*  of  the  form  begin  D*  5* 
end.  For  each  procedure 

proc  p(val  x,  res  y)  is* n  S  end*1 


in  £>*,  the  aim  is  to  determine  the  set  IAV(p)  of  global  variables  that  might 
be  assigned  directly  or  indirectly  when  p  is  called. 

To  compute  these  sets  we  need  two  auxiliary  notions.  The  set  AV(S)  of 
directly  assigned  variables  gives  for  each  statement  S  the  set  of  variables 
that  could  be  assigned  in  S  -  but  ignoring  the  effect  of  procedure  calls.  It  is 
defined  inductively  upon  the  structure  of  S: 


AV([skip]*) 
AV([x  :=  a]*) 
AV(Si;S2) 
AV(if  [6]*  then  Si  else  S2) 
AV(while  [6]*  .do  S) 
AVQcall  p(a,  z)]*°) 


0 

{x} 

AV(Si)  U  AV(S2) 
AV(Si)  U  AV(S2) 
AV(S) 

{*} 


Similarly  we  shall  need  the  set  CP(S)  of  immediately  called  procedures  that 
gives  for  each  statement  5  the  set  of  procedure  names  that  could  be  directly 
called  in  S  -  but  ignoring  the  effect  of  procedure  calls.  It  is  defined  inductively 
upon  the  structure  of  S: 


CP([skip]*) 
CP{[x  :=  a]*) 
CP(Si;S2) 
CP( if  [6]*  then  Si  else  S2) 
CP(while  [6]*  do  S) 
CP([ call  p(a,z)]e(l) 


CP(Si)  U  CP(S2) 
CP{Si)  U  CP{S2) 
CP{S) 

{P} 


Both  the  sets  AV(S)  and  CP(S)  are  well-defined  by  induction  on  the  structure 
of  5;  also  it  should  be  clear  that  they  are  context-insensitive  in  the  sense  that 
any  rearrangement  of  the  statements  inside  S  would  have  given  the  same 
result.  The  information  in  CP(-  •  •)  can  be  presented  graphically:  let  the 
graph  have  a  node  for  each  procedure  name  as  well  as  a  node  called  main* 
for  the  program  itself,  and  let  the  graph  have  an  edge  from  p  (respectively 
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main*)  to  p'  whenever  the  procedure  body  S  of  p  has  p'  €  CP(S)  (respectively 
p'  e  CP(Sir)).  This  graph  is  usually  called  the  procedure  call  graph. 

We  can  now  formulate  a  system  of  data  flow  equations  that  specifies  how  to 
obtain  the  desired  sets  IAV(p ): 

IAV(p)  =  (AV(S)  \  {x})  u  \J{iAV(p')  I  p'  e  CP(S)} 

where  proc  p(val  x,  res  y)  is *"S  end*1  is  in  D* 

By  analogy  with  the  considerations  in  Section  2.1  we  want  the  least  solution 
of  this  system  of  equations. 

Example  2.42  Let  us  now  consider  the  following  version  of  the  Fibonacci 
program  (omitting  labels): 

begin  proc  fib(val  z)  is  if  z<3  then  call  add(l) 

else  (call  fib(z-l);  call  fib(z-2)) 

end; 

proc  add(val  u)  is  (y:=y+u;  u:=0) 
end; 

y:=0;  call  fib(x) 

end 

We  then  get  the  following  equations 

IAV(  fib)  =  (0\{z})UlAV(fib)UJAV(add) 

I4V(add)  =  {y,u}\{u} 

The  associated  procedure  call  graph  is  shown  in  Figure  2.11.  The  least  solu¬ 
tion  to  the  equation  system  is 

IAV(f  ib)  =  JAV(add)  =  {y} 

showing  that  only  the  variable  y  will  be  assigned  by  the  procedure  calls. 
(Had  we  instead  taken  the  greatest  solution  to  the  equations  we  would  have 
IAV( fib)  =  IAV(add)  =  Var*  for  any  set  Var*  of  variables  that  contains 
those  used  in  the  program  and  this  would  be  completely  unusable.)  ■ 

Note  that  the  formulation  of  the  example  analysis  did  not  associate  infor¬ 
mation  with  entries  and  exit  of  blocks  but  rather  with  the  blocks  (or  more 
generally  the  statements)  themselves.  This  is  a  rather  natural  space  saving 
approach  for  a  context-insensitive  analysis.  It  also  relates  to  the  discussion 
of  Type  and  Effect  Systems  in  Section  1.6:  the  “annotated  base  types”  in 
Table  1.2  versus  the  “annotated  type  constructors”  in  Table  1.3. 
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Figure  2.11:  Procedure  call  graph  for  example  program. 


2.6  Shape  Analysis 

We  shall  now  study  an  extension  of  the  WHiLE-language  with  heap  allocated 
data  structures  and  an  interprocedural  Shape  Analysis  that  gives  a  finite 
characterisation  of  the  shapes  of  these  data  structures.  So  while  the  aim  of 
the  previous  sections  has  been  to  present  the  basic  techniques  of  Data  Flow 
Analysis,  the  aim  of  this  section  is  to  show  how  the  techniques  can  be  used 
to  specify  a  rather  complex  analysis. 

Shape  analysis  information  is  not  only  useful  for  classical  compiler  optimisa¬ 
tions  but  also  for  software  development  tools:  the  Shape  Analysis  will  allow 
us  to  statically  detect  errors  like  dereferencing  a  nil-pointer  -  this  is  guar¬ 
anteed  to  give  rise  to  a  dynamic  error  and  a  warning  can  be  issued.  Perhaps 
more  surprisingly,  the  analysis  allows  us  to  validate  certain  properties  of  the 
shape  of  the  data  structures  manipulated  by  the  program;  we  can  for  exam¬ 
ple  validate  that  a  program  for  in-situ  list  reversal  does  indeed  transform  a 
non-cyclic  list  into  a  non-cyclic  list. 

Syntax  of  the  pointer  language.  We  shall  study  an  extension  of 
While  that  allows  us  to  create  cells  in  the  heap;  the  cells  are  structured  and 
may  contain  values  as  well  as  pointers  to  other  cells.  The  data  stored  in  a 
cell  is  accessed  via  selectors  so  we  assume  that  a  finite  and  non-empty  set 
Sel  of  selector  names  are  given: 

sel  €  Sel  selector  names 

As  an  example  Sel  may  include  the  Lisp-like  selectors  cdr  and  car  for  select¬ 
ing  the  first  and  second  components  of  pairs.  The  cells  of  the  heap  can  be 
addressed  by  expressions  like  x.cdr:  this  will  first  determine  the  cell  pointed 
to  by  the  variable  x  and  then  return  the  value  of  the  cdr  field.  For  the  sake  of 
simplicity  we  shall  only  allow  one  level  of  selectors  although  the  development 
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generalises  to  several  levels.  Formally  the  pointer  expressions  are  given  by: 

p  ::=  a;  |  x.sel 

The  syntax  of  the  WHiLE-language  is  now  extended  to  have: 
a  ::=  p\n\  ai  opa  a2  |  nil 

b  ::=  true  |  false  |  not  b  |  bi  opb  &2  |  fli  opr  a2  j  opp  p 

S  ::=  \p-.=a}1  |  [skip]*  |  Si;  S2  | 

if  [£>]*  then  Si  else  S2  |  while  [&]*  do  S  | 

[malloc  p\l 

Arithmetic  expressions  are  extended  to  use  pointer  expressions  rather  than 
just  variables,  and  an  arithmetic  expression  can  also  be  the  constant  nil. 
The  binary  operations  opa  are  as  before,  that  is,  they  are  the  standard  arith¬ 
metic  operations  and  in  particular  they  do  not  allow  pointer  arithmetic.  The 
boolean  expressions  are  extended  such  that  the  relational  operators  opr  now 
allow  testing  for  the  equality  of  pointers  and  also  we  shall  allow  unary  opera¬ 
tions  opp  on  pointers  (as  for  example  is -nil  and  has -sel  for  each  sel  €  Sel). 
Note  that  arithmetic  as  well  as  boolean  expressions  can  only  access  cells  in 
the  heap,  they  cannot  create  new  cells  nor  update  existing  cells. 

The  assignment  statement  takes  the  general  form  p :  =a  where  p  is  a  pointer 
expression.  In  the  case  where  p  is  just  a  variable  we  have  an  extension  of  the 
ordinary  assignment  of  the  WHILE  language  and  in  the  case  where  p  contains 
a  selector  we  have  a  destructive  update  of  the  heap.  The  statements  of  the 
extended  language  also  contain  a  statement  malloc  p  for  creating  a  new  cell 
pointed  to  by  p. 

Example  2.43  The  following  program  reverses  the  list  pointed  to  by  x 
and  leaves  the  result  in  y: 

[y:=nil]x; 

while  [not  is-nil(x)]2  do 

([z:=y]3;  [y:=x]4;  [x:=x.cdr]5;  [y.cdr:=z]6); 

[z :  =nil]7 

Figure  2.12  illustrates  the  effect  of  the  program  when  x  points  to  a  five 
element  list  and  y  and  z  are  initially  undefined.  Row  0  shows  the  heap  just 
before  entering  the  while-loop:  x  points  to  the  list  and  y  is  nil  (denoted 
by  o);  to  avoid  cluttering  the  figure  we  do  not  draw  the  car-pointers.  After 
having  executed  the  statements  of  the  body  of  the  loop  the  situation  is  as  in 
row  1:  x  now  points  to  the  tail  of  the  list,  y  points  to  the  head  of  the  list  and 
z  is  nil.  In  general  the  n’th  row  illustrates  the  situation  just  before  entering 
the  loop  the  n  +  l’th  time  so  in  row  5  we  see  that  x  points  to  nil  and  the 
execution  of  the  loop  terminates  and  y  points  to  the  reversed  list.  The  final 
statement  z:=nil  simply  removes  the  pointer  from  z  to  £4  and  sets  it  to  the 
nil-value.  ■ 
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0:  y  - 

z 


l:  y  — ^iry^o 

z  - ►  o 


Figure  2.12:  Reversal  of  a  list  of  five  elements. 


2.6.1  Structural  Operational  Semantics 

To  model  the  scenario  described  above  we  shall  introduce  an  infinite  set  Loc 
of  locations  (or  addresses)  for  the  heap  cells: 


£  €  Loc 


locations 
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The  value  of  a  variable  will  now  either  be  an  integer  (as  before),  a  location 
(i.e.  a  pointer)  or  the  special  constant  o  reflecting  that  it  is  the  nil  value. 
Thus  the  states  are  given  by 

a  £  State  =  Var*  — ►  (Z  +  Loc  +  {o}) 

where  as  usual  Var*  is  the  (finite)  set  of  variables  occurring  in  the  program 
of  interest.  As  mentioned  above  the  cells  of  the  heap  have  multiple  fields  and 
they  are  accessed  using  the  selectors.  Each  field  can  either  be  an  integer,  a 
pointer  to  another  cell  or  it  can  be  nil.  We  formalise  this  by  taking 

H  £  Heap  =  (Loc  x  Sel)  ->fln  (Z  +  Loc  +  {o}) 

Note  that  the  use  of  partial  functions  reflects  that  not  all  selector  fields  need 
to  be  defined;  as  we  shall  see  later,  a  newly  created  cell  with  location  £  will 
have  all  its  fields  to  be  uninitialised  and  hence  the  corresponding  heap  u  will 
have  «(£,  sel)  to  be  undefined  for  all  sel  €  Sel. 

Pointer  expressions.  Given  a  state  and  a  heap  we  need  to  determine 
the  value  of  a  pointer  expression  p  as  an  element  of  Z  +  Loc  +  {o}.  For  this 
we  introduce  the  function 

p  :  Var  -*  (State  x  Heap)  -»fin  (z  +  M  +  Loc) 


(*) 

n(a(x),sel) 

if  ct(x)  €  Loc  and  n  is  defined  on  ( a[x ),  sel) 
undef 

if  a(x)  £  Loc  or  u  is  undefined  on  ( cr(x ),  sel) 

The  first  clause  takes  care  of  the  situation  where  p  is  a  simple  variable  and 
using  the  state  we  determine  its  value  -  note  that  this  may  be  an  integer, 
a  location  or  the  special  nil-value  o.  The  second  clause  takes  care  of  the 
case  where  the  pointer  expression  has  the  form  x.sel.  Here  we  first  have  to 
determine  the  value  of  x\  it  only  makes  sense  to  inspect  the  sef-field  in  the 
case  x  evaluates  to  a  location  that  has  a  sel-field  and  hence  the  clause  is  split 
into  two  sub-cases.  In  the  case  where  x  evaluates  to  a  location  we  simply 
inspect  the  heap  n  to  determine  the  value  of  the  sef-field  -  again  we  may 
note  that  this  can  be  an  integer,  a  location  or  the  special  value  o. 

Example  2.44  In  Figure  2.12  the  oval  nodes  model  the  cells  of  the  heap 
n  and  they  are  labelled  with  their  location  (or  address).  The  unlabelled  edges 
denote  the  state  a:  an  edge  from  a  variable  x  to  some  node  labelled  £  means 
that  a(x)  =  £;  an  edge  from  x  to  the  symbol  o  means  that  o(x)  —  o.  The 
labelled  edges  model  the  heap  n:  an  edge  labelled  sel  from  a  node  labelled 


defined  by 

p[x](o-,-H)  =  o 

p[x.se/](<r,w)  =  < 
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f  to  a  node  labelled  £'  means  that  there  is  a  sel  pointer  between  the  two 
cells,  that  is  h(£,  sel)  =  an  edge  labelled  sel  from  a  node  labelled  £  to  the 
symbol  o  means  that  the  pointer  is  a  nil-pointer,  that  is  w(£,  sel)  =  o. 

Consider  the  pointer  expression  x.cdr  and  assume  that  a  and  n  are  as  in  row  0 
of  Figure  2.12,  that  is  tr(x)  =  fi  and  w(£i,  cdr)  =  Then  p[x.cdr](cr, u)  — 
6-  ■ 


Arithmetic  and  boolean  expressions.  It  is  now  straightforward 
to  extend  the  semantics  of  arithmetic  and  boolean  expressions  to  handle 
pointer  expressions  and  the  nil-constant.  Obviously  the  functionality  of  the 
semantic  functions  A  and  B  have  to  be  changed  to  take  the  heap  into  account: 

A  :  AExp  -»  (State  x  Heap)  ->fin  (Z  +  Loc  +  {o}) 

B  :  BExp  (State  x  Heap)  -4fin  T 


The  clauses  for  arithmetic  expressions  are 


A[p1(ct,-h) 
A[n\{cj,n) 
A{av  opa  a2](a,n) 
-4[nil]  (cr,n) 


p[p](a,n) 

Af[n] 

A[ai](<r,«)  opa  A[a2 ]((r,n) 


where  we  use  p  to  determine  the  value  of  pointer  expressions  and  we  explicitly 
write  that  the  meaning  of  nil  is  o/- Also  the  meaning  op0  of  the  binary  oper¬ 
ation  opa  has  to  be  suitably  modified  to  be  undefined  unless  both  arguments 
are  integers  in  which  case  the  results  are  as  for  the  WHILE-language. 

The  definition  of  the  semantics  of  boolean  expressions  is  similar  so  we  only 
give  two  of  the  clauses: 

B[ai  opr  a2](a,-H)  =  A[ai](a,-u)  opr  A[a2\{o,u) 
Bloppp\{a,u)  =  opp  (p\p](a,u)) 

Analogously  to  above,  the  meaning  opr  of  the  binary  relation  operator  opT 
has  to  be  suitably  modified  to  give  undefined  in  case  the  arguments  are  not 
integers  except  that  the  equality  operation  now  allows  testing  for  the  equality 
of  pointers.  The  meaning  of  the  unary  operation  opp  is  defined  by  opp;  as 
an  example: 

.  ,  f  tt  if  v  —  o 

is  m  (v)  —  |  ^  otherwise 


Statements.  Finally,  the  semantics  of  statements  is  extended  to  cope 
with  the  heap  component.  The  configurations  will  now  contain  a  state  as 
well  as  a  heap  so  we  have 

([x:=q]/,ct,'H)  (<r[a;  *->■  A[a|(cr,H)],H) 

if  A|a](cr,  h)  is  defined 
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reflecting  that  for  the  assignment  x :  =a  the  state  is  updated  as  usual  and  the 
heap  is  left  unchanged.  In  the  case  where  we  assign  to  a  pointer  expression 
containing  a  selector  field  we  shall  leave  the  state  unchanged  and  update  the 
heap  as  follows: 

{[x.sel-.=a]1  ,cr,  n)  ->  (a,  n[(a(x),sel)  *4[a](cr, «)]) 

if  a(x)  6  Loc  and  A[a](a,n)  is  defined 

Here  the  side  condition  ensures  that  the  left  hand  side  of  the  assignment  does 
indeed  evaluate  to  a  location. 

The  construct  malloc  p  is  responsible  for  creating  a  new  cell.  We  have  two 
clauses  depending  on  the  form  of  p : 

{[malloc  x]e,a,  n)  -»  (a[x  t->  £],«) 

where  £  does  not  occur  in  a  or  u 

([malloc  (x.sel)]e,a,  u)  ->  (a,  u[{p(x),  sel)  i->  £]) 

where  £  does  not  occur  in  a  or  n  and  a{x)  €  Loc 

Note  that  in  both  cases  we  introduce  a  fresh  location  £  but  we  do  not  specify 
any  values  for  «(£,  sel)  -  as  discussed  before  we  have  settled  for  a  semantics 
where  the  fields  of  £  are  undefined;  obviously  other  choices  are  possible.  Also 
note  that  in  the  last  clause  the  side  condition  ensures  that  we  already  have  a 
location  corresponding  to  x  and  hence  can  create  an  edge  to  the  new  location. 

Remark.  The  semantics  only  allows  a  limited  reuse  of  garbage  locations. 
For  a  statement  like  [malloc  x]1;  [x:=nil]2;  [malloc  y]3  we  will  assign  some 
location  to  x  at  the  statement  with  label  1  and  since  it  neither  occurs  in 
the  state  nor  the  heap  after  the  assignment  labelled  2  we  are  free  to  reuse 
it  in  the  statement  labelled  3  (but  we  do  not  have  to).  For  a  statement  like 
[malloc  x]1;  [x.cdr:=nil]2;  [x:=nil]3;  [malloc  y]4  we  would  not  be  able  to 
reuse  the  location  allocated  at  1  although  it  will  be  unreachable  (and  hence 
garbage)  after  the  statement  labelled  3.  ■ 

2.6.2  Shape  Graphs 

It  should  be  evident  that  there  are  programs  for  which  the  heap  can  grow 
arbitrarily  large.  Therefore  the  aim  of  the  analysis  will  be  to  come  up  with 
finite  representations  of  it.  To  do  so  we  shall  introduce  a  method  for  com¬ 
bining  the  locations  of  the  semantics  into  abstract  locations  such  that  there 
is  only  a  finite  number  of  abstract  locations.  We  then  introduce  an  abstract 
state  S  mapping  variables  to  abstract  locations  (rather  than  locations)  and 
an  abstract  heap  H  specifying  the  links  between  the  abstract  locations  (rather 
than  the  locations).  More  precisely,  the  analysis  will  operate  on  shape  graphs 
(S,  H,  is)  consisting  of: 

•  an  abstract  state,  S, 
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•  an  abstract  heap,  H,  and 

•  sharing  information,  is,  for  the  abstract  locations. 

The  last  component  allows  us  to  recover  some  of  the  imprecision  introduced 
by  combining  many  locations  into  one  abstract  location.  We  shall  now  de¬ 
scribe  how  a  given  state  a  and  heap  w  give  rise  to  a  shape  graph  (S,  H,  is);  in 
doing  so  we  shall  specify  the  functionality  of  S,  H  and  is  in  detail  as  well  as 
formulating  a  total  of  five  invariants. 

Abstract  locations.  The  abstract  locations  have  the  form  nx  where 
X  is  a  subset  of  the  variables  of  Var*: 

ALoc  =  {nx  |  X  C  Var*}  abstract  locations 

Since  Var*  is  finite  it  is  clear  that  ALoc  is  finite  and  a  given  shape  graph 
will  contain  a  subset  of  the  abstract  locations  of  ALoc. 

The  idea  is  that  if  x  €  X  then  the  abstract  location  nx  will  (among  oth¬ 
ers)  represent  the  location  o(x).  The  abstract  location  ng  is  called  the  ab¬ 
stract  summary  location  and  it  will  represent  all  the  locations  that  cannot  be 
reached  directly  from  the  state  without  consulting  the  heap.  Clearly  nx  and 
ng  will  represent  disjoint  sets  of  locations  when  X  /  0. 

In  general,  we  shall  enforce  the  invariant  that  two  distinct  abstract  locations 
nx  and  ny  always  represent  disjoint  sets  of  locations.  As  a  consequence 
we  get  that  for  any  two  abstract  locations  nx  and  ny  it  is  either  the  case 
that  X  =  Y  or  that  X  n  Y  =  0.  To  see  this  assume  that  X  ^  Y  and  that 
z  €  XDY.  From  z  €  X  we  get  that  o(z)  is  represented  by  nx  and  similarly 
z  £Y  gives  that  o(z)  is  represented  by  ny.  Hence  nx  and  ny  must  be  equal 
and  we  have  a  contradiction. 

The  invariant  can  be  formulated  as  follows: 

Invariant  1.  If  two  abstract  locations  nx  and  ny  occur  in  the  same 
shape  graph  then  either  X  =  Y  or  XDY  =  </). 


Example  2.45  Consider  the  state  and  heap  in  row  2  of  Figure  2.12.  The 
variables  x,  y  and  z  point  to  different  locations  (£3,  £2,  and  £1,  respectively) 
so  in  the  shape  graph  they  will  be  represented  by  different  abstract  locations 
named  n{x},  ri{y}  and  n{z}-  The  two  locations  £4  and  £5  cannot  be  reached 
directly  from  the  state  so  they  will  be  represented  by  the  abstract  summary 
location  ng.  ■ 

Abstract  states.  One  of  the  components  of  a  shape  graph  is  the  ab¬ 
stract  state,  S,  that  maps  variables  to  abstract  locations.  To  maintain  the 
naming  convention  for  abstract  locations  we  shall  ensure  that: 
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Figure  2.13:  Shape  graphs  corresponding  to  Figure  2.12. 


Invariant  2.  If  x  is  mapped  to  nx  by  the  abstract  state  then  x  6  X. 

From  Invariant  1  it  follows  that  there  will  be  at  most  one  abstract  location 
in  the  shape  graph  containing  a  given  variable. 

We  shall  only  be  interested  in  the  shape  of  the  heap  so  we  shall  not  distinguish 
between  integer  values,  nil-pointers  and  uninitialised  fields;  hence  we  can 
view  the  abstract  state  as  an  element  of 

S  G  AState  =  V(Vax*  x  ALoc) 

where  we  have  chosen  to  use  powersets  so  as  to  simplify  the  notation  in  later 
parts  of  the  development.  We  shall  write  ALoc( S)  =  {nx  |  3x  :  (x,  rix)  G  S} 
for  the  set  of  abstract  locations  occurring  in  S.  (Note  that  AState  is  too 
large  in  the  sense  that  it  contains  elements  that  do  not  satisfy  the  invariants.) 

Abstract  heaps.  Another  component  of  the  shape  graph  is  the  abstract 
heap,  H,  that  specifies  the  links  between  the  abstract  locations  (just  as  the 
heap  specifies  the  links  between  the  locations  in  the  semantics).  The  links 
will  be  specified  by  triples  {ny  ,sel,nw)  and  formally  we  take  the  abstract 
heap  as  an  element  of 

H  G  AHeap  =  T^ALoc  x  Sel  x  ALoc) 

where  we  again  do  not  distinguish  between  integers,  nil-pointers  and  unini¬ 
tialised  fields.  We  shall  write  ALoc{ H)  =  {ny,n\y  |  3 sel :  (ny,  sel,nw)  €  H} 
for  the  set  of  abstract  locations  occurring  in  H. 
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The  intention  is  that  if  w(£i,  sei)  =  £2  and  £1  and  £2  are  represented  by  ny 
and  nw,  respectively,  then  ( ny,sel,nw )  €  H. 

In  the  heap  n  there  will  be  at  most  one  location  £2  such  that  n((,i,sel)  = 
£2.  The  abstract  heap  only  partly  shares  this  property  because  the  abstract 
location  n0  can  represent  several  locations  pointing  to  different  locations. 
However,  the  abstract  heap  must  satisfy: 

Invariant  3.  Whenever  ( ny,sel,nw )  and  (ny,sel,nw')  are  in  the 
abstract  heap  then  either  V  =  0  or  W  =  W1. 

Thus  the  target  of  a  selector  field  will  be  uniquely  determined  by  the  source 
unless  the  source  is  the  abstract  summary  location  n0. 

Example  2.46  Continuing  Example  2.45  we  can  now  see  that  the  ab¬ 
stract  state  S2  corresponding  to  the  state  of  row  2  of  Figure  2.12  will  be 

S2  =  {(x,n{l}),(y,n{y}),(z,n{2})} 

The  abstract  heap  H2  corresponding  to  row  2  has 

H2  =  {(n{2},cdr,n0),(n0,cdr,n0),(n{y},cdr,n{2j)} 

The  first  triple  reflects  that  the  heap  maps  £3  and  cdr  to  £4,  £3  is  represented 
by  ri{ x}  and  £4  is  represented  by  The  second  triple  reflects  that  the  heap 
maps  £4  and  cdr  to  £5  and  both  £4  and  £5  are  represented  by  n0.  The  final 
triple  reflects  that  the  heap  maps  £2  and  cdr  to  £1,  £2  is  represented  by  n^y 
and  £1  is  represented  by  nyzy.  Note  that  there  is  no  triple  (ri{z},cdr, n0) 
because  the  heap  maps  £1  and  cdr  to  o  rather  than  a  location. 

The  resulting  abstract  state  and  abstract  heap  is  illustrated  in  Figure  2.13 
together  with  similar  information  for  the  other  states  and  heaps  of  Figure 
2.12.  The  square  nodes  model  abstract  locations;  the  unlabelled  edges  from 
variables  to  square  nodes  model  the  abstract  state  and  the  labelled  edges 
between  square  nodes  model  the  abstract  heap.  If  the  abstract  state  does 
not  associate  an  abstract  location  with  some  variable  then  that  variable  does 
not  occur  in  the  picture. 

Note  that  even  if  the  semantics  uses  the  same  locations  throughout  the 
computation  it  need  not  be  the  case  that  the  locations  are  associated  with 
the  same  abstract  locations  at  all  points  in  the  analysis.  Consider  Figures 
2.12  and  2.13:  the  abstract  location  n0  will  in  turn  represent  the  locations 
{^3,  ^4,  £5},  {£t, £5},  {£i,&}i  {616}  and  {£1.62, &}•  ■ 

Sharing  information.  We  are  now  ready  to  introduce  the  third  and 
final  component  of  the  shape  graphs.  Consider  the  top  row  of  Figure  2.11. 
The  abstract  state  and  abstract  heap  to  the  right  represent  the  state  and  the 
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cdr 


Figure  2.14:  Sharing  information. 


heap  to  the  left  but  they  also  represent  the  state  and  the  heap  shown  in  the 
second  row.  We  shall  now  show  how  to  distinguish  between  these  two  cases. 

The  idea  is  to  specify  a  subset,  is,-  of  the  abstract  locations  that  represent 
locations  that  are  shared  due  to  pointers  in  the  heap:  an  abstract  location 
nx  will  be  included  in  is  if  it  does  represent  a  location  that  is  the  target  of 
more  than  one  pointer  in  the  heap.  In  the  top  row  of  Figure  2.14,  the  abstract 
location  represents  the  location  £5  and  it  is  not  shared  (by  two  or  more 
heap  pointers)  so  ri{y}  ^  is;  the  fat  box  indicates  that  the  abstract  location  is 
unshared.  On  the  other  hand,  in  the  second  row  £5  is  shared  (both  £3  and  £4 
point  to  it)  so  nyyy  €  is;  the  double  box  indicates  that  the  abstract  location 
might  be  shared. 

Obviously,  the  abstract  heaps  themselves  also  contain  some  implicit  sharing 
information:  this  is  illustrated  in  the  bottom  row  of  Figure  2.14  where  there 
are  two  distinct  edges  with  target  ny7y.  We  shall  ensure  that  this  implicit 
sharing  information  is  consistent  with  the  explicit  sharing  information  (as 
given  by  is)  by  imposing  two  invariants.  The  first  ensures  that  information 
in  the  sharing  component  is  also  reflected  in  the  abstract  heap: 

Invariant  4.  If  nx  €  is  then  either 

(a)  (ri0,sel,nx)  is  in  the  abstract  heap  for  some  sel,  or 

(b)  there  exists  two  distinct  triples  (nv,sel\,nx)  and  (n\y,sel2,nx) 
in  the  abstract  heap  (that  is  either  sel  1  ^  selz  or  V  ^  W). 
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Case  4(a)  takes  care  of  the  situation  where  there  might  be  several  locations 
represented  by  n®  that  point  to  nx  (as  in  the  second  row  of  Figure  2.14). 
Case  4(b)  takes  care  of  the  case  where  two  distinct  pointers  (with  different 
source  or  different  selectors)  point  to  nx  (as  in  the  bottom  row  of  Figure 
2.14). 

The  second  invariant  ensures  that  sharing  information  present  in  the  abstract 
heap  is  also  reflected  in  the  sharing  component: 

Invariant  5.  Whenever  there  are  two  distinct  triples  (ny,seli,nx) 
and  (nw,  sel 2,  nx)  in  the  abstract  heap  and  nx  /  n$  then  nx  G  is. 

This  takes  care  of  the  case  where  nx  represents  a  single  location  being  the 
target  of  two  or  more  heap  pointers  (as  in  the  bottom  row  of  Figure  2.14). 
Note  that  invariant  5  is  the  “inverse”  of  invariant  4(b)  and  that  we  have  no 
“inverse”  of  invariant  4(a)  -  the  presence  of  a  pointer  from  to  nx  gives 
no  information  about  sharing  properties  of  nx  ■ 

In  the  case  of  the  abstract  summary  location  the  explicit  sharing  information 
clearly  gives  extra  information:  if  n g  €  is  then  there  might  be  a  location 
represented  by  n@  that  is  the  target  of  two  or  more  heap  pointers,  whereas 
if  7i0  £  is  then  all  the  locations  represented  by  ng  will  be  the  target  of  at 
most  one  heap  pointer.  The  explicit  sharing  information  may  also  give  extra 
information  for  abstract  locations'  nx  where  I  /  ®:  from  4(a)  alone  we 
cannot  deduce  that  nx  is  shared  -  this  is  clearly  illustrated  for  the  node  ri{yj 
by  the  top  two  rows  of  Figure  2.14. 

The  complete  lattice  of  shape  graphs.  To  summarise,  a  shape 
graph  is  a  triple  consisting  of  an  abstract  state  S,  an  abstract  heap  H,  and  a 
set  is  of  abstract  locations  that  are  shared: 

S  G  AState  =  T^Var*  x  ALoc) 

H  G  AHeap  =  ^(ALoc  x  Se!  x  ALoc) 

is  G  IsShared  =  ^(ALoc) 

where  ALoc  =  {nz  \  Z  C  Var*}.  A  shape  graph  (S,  H,  is)  is  a  compatible 
shape  graph  if  it  fulfils  the  five  invariants  presented  above: 

1.  Wny,nw  G  ALoc(  S)  U  ALoc(  H)  U  is  :  V  =  W  V  V  fl  W  =  0 

2.  V(x,nx)  G  S  :  x  G  X 

3.  V(nv,  sel,nw),  (nv,  sel,nw)  G  H  :  V  =  0  V  W  =  W' 

4.  Vnx  G  is  :  (3 sel :  (na,seZ,nx)  G  H)  V 

(3(nv ,  sell, nx),  (nw ,  sell, nx)  €  H  : 

seh  ±  sel2  vy/lf) 
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Figure  2.15:  The  extremal  value  t  for  the  list  reversal  program. 


5.  V(nv,  sell, nx),  (nw,sel2,nx)  €  H  : 

((sell  5^  sel2  V  V  W)  A  X  ^  0)  =>•  nx  €  is 

The  set  of  compatible  shape  graphs  is  denoted 

SG  =  {(S,  H,  is)  |  (S,  H,  is)  is  compatible} 

and  the  analysis,  to  be  called  Shape,  will  operate  over  sets  of  compatible 
shape  graphs,  i.e.  elements  of  V(SG).  Since  V(SG)  is  a  powerset,  it  is 
trivially  a  complete  lattice  with  LI  being  U  and  C  being  C. 


2.6.3  The  Analysis 


The  analysis  will  be  specified  as  an  instance  of  a  Monotone  Framework  with 
the  complete  lattice  of  properties  being  V(SG).  For  each  label  consistent 
program  5*  with  isolated  entries  we  obtain  a  set  of  equations  of  the  form 


ShapeQ(£) 


ft  if  £  —  inii(5*) 

\  \J{Shapc,(£')  |  (£',£)  €  fiow(S*)}  otherwise 


Shape,(£)  =  ffA(Shape0(£)) 


where  t  €  V(SG)  is  the  extremal  value  holding  at  entry  to  5*  and  ffA  are  the 
transfer  functions  to  be  developed  below.  The  analysis  is  a  forward  analysis 
since  it  is  defined  in  terms  of  the  set  fiow(5*),  and  it  is  a  may  analysis  since 
we  are  using  |J  as  the  combination  operation. 


Example  2.47  Consider  again  the  list  reversal  program  of  Example  2.43 
and  assume  that  x  initially  points  to  an  unshared  list  with  at  least  two  el¬ 
ements  and  that  y  and  z  are  initially  undefined;  the  singleton  shape  graph 
corresponding  to  this  state  and  heap  is  illustrated  in  Figure  2.15  and  will  be 
the  extremal  value  i  used  throughout  this  development. 

The  Shape  Analysis  computes  the  sets  Shape0(£ )  and  Shape,  (£)  of  shape 
graphs  describing  the  state  and  heap  before  and  after  executing  the  elemen¬ 
tary  block  labelled  £.  The  equations  for  Shape,  (£)  are 

Shape,  (1)  =  ffA(Shape0(l))  =  f?A(i) 

Shape,(2)  =  /fA(Shape0(2))  =  /fA (Shape, (1)  U  Shape, (6)) 
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Figure  2.16:  Shape  graphs  computed  for  the  list  reversal  program  (part  1) 


Shape.  (3)  =  /fA  (Shape.  (3))  =  /fA  (Shape.  (2)) 

Shape.  (4)  =  /4SA(Shape0(4))  =  /fA  (Shape.  (3)) 

Shape,  (5)  =  /5SA(Shape0(5))  =  /fA  (Shape.  (4)) 

Shape,  (6)  =  /|A  (Shape,  (6))  =  /|A  (Shape.  (5)) 
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Figure  2.17:  Shape  graphs  computed  for  the  list  reversal  program  (part  2). 

Shape,  (7)  =  /7SA(Shape0(7))  =  /7SA(Shape.(2)) 

where  the  transfer  functions  ffA  will  be  specified  below.  The  least  solution 
to  the  equations  is  shown  in  Figures  2.16  and  2.17;  the  sets  Shape,(£)  contain 
between  1  and  4  distinct  shape  graphs. 

From  Shape,  (2)  we  can  see  that  at  the  beginning  of  each  iteration  of  the  loop 
it  is  the  case  that 

•  x  never  points  to  a  shared  list, 

•  y  never  points  to  a  shared  list, 
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•  z  may  point  to  the  second  element  of  the  list  pointed  to  by  y  (if  it 
exists),  and 

•  x  and  y  never  point  to  lists  that  are  not  disjoint  (because  is  not 
shared). 

The  shape  graphs  in  Shape ,  (7)  show  that  at  termination  y  cannot  point  to 
a  shared  list  -  it  will  not  be  possible  that  the  list  is  cyclic  since  such  a  list 
cannot  be  represented  by  any  of  the  shape  graphs  in  Shape, (7).  m 

The  transfer  function  ffA  :  "P(SG)  -¥  'P(SG)  associated  with  a  label,  l,  has 
the  form: 

ff\SG)  =  A((S,  H,  is))  |  (S,H,is)  e  SG} 

where  <f>^A  :  SG  -» "P(SG)  specifies  how  a  single  shape  graph  (in  Shape0(i)) 
may  be  transformed  into  a  set  of  shape  graphs  (in  Shape,  (£))  by  the  elemen¬ 
tary  block  labelled  i.  We  shall  now  inspect  the  various  forms  of  elementary 
block  and  specify  <p^A  in  each  case.  We  shall  first  consider  the  boolean  ex¬ 
pressions  and  the  skip-statement,  then  the  different  forms  of  assignments 
and  finally  the  malloc-statement. 

Transfer  function  for  [&]*  and  [skip]^.  We  are  only  interested  in 
the  shape  of  the  heap  and  the  boolean  tests  do  not  modify  the  heap.  Hence 
we  take 

0/A((S,  H,  is))  =  {(S,  H,  is)} 

so  that  the  transfer  function  /|A  will  be  the  identity  function.  Similarly  for 
the  skip-statement. 

Example  2.48  This  case  is  illustrated  by  the  test  [not  is-nil(x)]2  of 
the  list  reversal  program  of  Example  2.43:  the  transfer  function  /f  A  is  the 
identity  function.  Hence  Shape, (2)  =  Shape.  (1)  U  Shape. (6)  in  Figures  2.16 
and  2.17.  ■ 


Transfer  function  for  \x :  =af  where  a  is  of  the  form  n,  oi  opa  02  or 
nil.  The  effect  of  this  assignment  will  be  to  remove  the  binding  to  x,  and 
to  rename  all  abstract  locations  so  that  they  do  not  include  x  in  their  name. 
The  renaming  of  abstract  locations  is  specified  by  the  function 

kx(nz)  = 


and  we  then  take 


11 


0fA((S,H,is))  =  {HfI((S,H,is))} 
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(S,  H,  is) 


(S',  H',is') 


Figure  2.18:  The  effect  of  [x:=nil]*. 


where  killx((S,  H,  is))  =  (S',  H',  is')  is  given  by 

S'  =  {(z,kx(nz))  |  (z,nz)  €  S  f\  z  ^  x) 

H'  =  {(kx(nv),sel,kx(nw))  |  (nv,sel,nw)  €  H} 
is'  =  {kx{nx)  |  nx  €  is} 

It  is  easy  to  check  that  if  (S,  H,  is)  is  compatible  then  so  is  (S',  H',  is'). 

Example  2.49  The  statement*  [y:=nil]x  of  the  list  reversal  program  of 
Example  2.43  is  of  the  form  considered  here.  Since  there  is  no  occurrence  of 
y  in  the  shape  graph  i  of  Figure  2.15,  the  shape  graph  Shape. (1)  in  Figure 
2.16  is  equal  to  t.  ■ 

An  interesting  case  is  when  ( x ,  nyxy)  €  S  since  this  will  cause  the  two  abstract 
locations  nyxy  and  ng  to  be  merged.  The  sharing  information  is  then  updated 
to  capture  that  we  can  only  be  sure  that  ng  is  unshared  in  the  updated  shape 
graph  if  both  n®  and  n^xy  were  unshared  in  the  original  shape  graph.  This  is 
illustrated  in  Figure  2.18:  the  left  hand  picture  shows  the  interesting  parts  of 
the  shape  graph  (S,  H,  is)  and  the  right  hand  picture  shows  the  corresponding 
parts  of  (S',  H',  is').  We  shall  assume  that  the  square  boxes  represent  distinct 
abstract  locations  so  in  particular  V,  {x},  W  and  0  are  all  distinct  sets. 
The  fat  boxes  represent  unshared  abstract  locations  as  before,  the  thin  boxes 
represent  abstract  locations  whose  sharing  information  is  not  affected  by  the 
transfer  function,  and  unlabelled  edges  between  abstract  locations  represent 
pointers  that  are  unaffected  by  the  transfer  function. 

Example  2.50  The  statement  [z:=nil]7  of  the  list  reversal  program  of 
Example  2.43  illustrates  this  case:  for  each  of  the  shape  graphs  of  Shape. (2) 
in  Figures  2.16  and  2.17  the  abstract  location  nyzy  is  merged  with  to 
produce  one  of  the  shape  graphs  of  Shape,  (7).  ■ 
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Figure  2.19:  The  effect  of  [x:=y]1  when  x^y. 


Remark.  The  analysis  does  not  perform  garbage  collection:  it  might  be 
the  case  that  there  are  no  heap  pointers  to  nyxy  and  then  the  corresponding 
location  in  the  heap  will  be  unreachable  after  the  assignment.  Nonetheless 
the  analysis  will  still  merge  the  two  abstract  locations  n{xy  and  n@  and  insist 
on  a  pointer  from  to  any  abstract  location  that  nyxy  might  point  to.  ■ 

Transfer  function  for  [x :  =y]*.  If  x  =  y  then  the  transfer  function 
ffA  is  just  the  identity. 

Next  suppose  that  x  ±  y.  The  first  effect  of  the  assignment  is  to  remove 
the  old  bindings  to  x;  for  this  we  use  the  killx  operation  introduced  above. 
Then  the  new  binding  to  x  is  recorded;  this  includes  renaming  the  abstract 
location  that  includes  y  in  its  variable  set  to  also  include  x.  The  renaming 
of  the  abstract  locations  is  specified  by  the  function: 

qy(n7)  =  l  nzu{l}  lf  y  G  Z 
^  \  nz  otherwise 

We  shall  then  take 

0fA((S)  H,is))  =  {(S",  H",  is")} 
where  (S',H',is')  =  killx(( S,  H,is))  and 

S"  =  {(z,9y(nz))\(z,nz)eS'} 

U  {(i,5*(»r))  I  {y',nY)  £  S'  Ay'  =  y} 

H"  =  {(9Unv),sel,gl{nw))  \  {nv,sel,nw)  e  H'} 
is"  =  {gyx{nz)  |  nz  €  is'} 

Here  the  second  clause  in  the  formula  for  S"  adds  the  new  binding  to  x. 
Again  we  note  that  if  (S,  H,  is)  is  compatible  then  so  is  (S",  H",  is"). 
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The  clause  is  illustrated  in  Figure  2.19  where  we  assume  that  nodes  represent 
distinct  abstract  locations;  it  follows  from  the  invariants  that  y  &Y  but  y  £  V 
and  y  $W.  Note  that  nYU[xy  inherits  the  sharing  properties  of  nY  although 
both  x  and  y  will  point  to  the  same  cell;  the  reason  is  that  the  sharing 
information  only  records  sharing  in  the  heap  -  not  sharing  via  the  state. 

Example  2.51  The  statement  [y  :=x]4  of  the  list  reversal  program  of  Ex¬ 
ample  2.43  is  of  the  form  considered  here:  each  of  the  shape  graphs  of 
Shape,  (3)  in  Figure  2.16  is  transformed  into  one  of  the  shape  graphs  of 
Shape,  (4). 

Also  the  statement  [z :  =y]3  is  of  the  form  considered  here:  each  of  the  shape 
graphs  of  Shape,  (2)  is  transformed  into  one  of  the  shape  graphs  of  Shape,  (3); 
indeed  two  of  the  shape  graphs  in  Shape,  (2)  give  rise  to  the  same  shape  graph 
in  Shape,  (3).  m 

Transfer  function  for  [x\=y.sel]1.  First  assume  that  x  =  y\  then 
the  assignment  is  semantically  equivalent  to  the  following  sequence  of  assign¬ 
ments 

[f :  =y.sel]ei ;  [a; :  =f]<2 ;  [t :  =nil]<3 

where  t  is  a  fresh  variable  and  t\,  ti  and  £3  are  fresh  labels.  The  transfer 
function  /|A  can  therefore  be  obtained  as 


where  the  transfer  functions  /f  A  and  ffA  follow  the  pattern  described  above. 
We  shall  therefore  concentrate  on  the  transfer  function  ffA,  or  equivalently, 
ffA  in  the  case  where  i/y. 

Example  2.52  The  statement  [x:=x.cdr]5  of  the  list  reversal  program  of 
Example  2.43  is  transformed  into  [t :  =x.cdr]51 ;  [x :  =t]52 ;  [t :  =nil]53 .  We  shall 
return  to  the  analysis  of  [t:=x.cdr]51  later.  ■ 

So  assume  that  x  ^  y  and  let  (S,  H,  is)  be  a  compatible  shape  graph  before 
the  analysis  of  the  statement.  As  in  the  previous  case,  the  first  step  will  be 
to  remove  the  old  binding  for  x  and  again  we  use  the  auxiliary  function  killx: 

(S',  H',  is')  =  killx((S,  H,  is)) 

The  next  step  will  be  to  rename  the  abstract  location  corresponding  to  y.sel 
to  include  x  in  its  name  and  to  establish  the  binding  of  x  to  that  abstract 
location.  We  can  now  identify  three  possibilities: 

1.  There  is  no  abstract  location  nY  such  that  ( y,nY )  £  S'  or  there  is 
an  abstract  location  nY  such  that  ( y,nY )  £  S'  but  no  nz  such  that 
(nY,sel,nz)  €  H';  in  this  case  the  shape  graph  will  represent  a  state 
and  a  heap  where  y  or  y.sel  is  an  integer,  nil  or  undefined. 
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Figure  2.20:  The  effect  of  [a; :  =y.se/]/  in  Case  2  when  x  7%. 


2.  There  is  an  abstract  location  ny  such  that  ( y,ny )  £  S'  and  there  is 
an  abstract  location  nu  i=-  n0  such  that  ( ny,sel,nu )  £  H';  in  this  case 
the  shape  graph  will  represent  a  state  and  a  heap  where  the  location 
pointed  to  by  y.sel  will  also  be  pointed  to  by  some  other  variable  (in 
U). 

3.  There  is  an  abstract  location  ny  such  that  ( y ,  ny)  £  S'  and  (ny,  sel,  n0) 
£  H';  in  this  case  the  shape  graph  will  represent  a  state  and  a  heap 
where  no  other  variable  points  to  the  location  pointed  to  by  y.sel. 

Case  1.  First  consider  the  statement  [x-.=y.sel]1  (where  x  ^  y)  in  the  case 
where  there  is  no  abstract  location  ny  such  that  (y,ny)  £  S'.  Then  there  is 
no  abstract  location  for  y.sel  and  hence  no  abstract  location  to  rename  and 
no  binding  to  establish.  Thus  we  take: 

0/A((S)H,is))  =  {&tffx((S,H,is))} 

Note  that  this  situation  captures  the  case  where  an  attempt  is  made  to  deref¬ 
erence  a  nil-pointer. 

Alternatively,  there  is  an  abstract  location  ny  such  that  ( y,ny )  £  S'  but  there 
is  no  abstract  location  n  such  that  ( ny,sel,n )  €  H'.  From  the  invariants  it 
follows  that  ny  is  unique  but  still  there  is  no  abstract  location  to  rename  and 
no  binding  to  establish.  So  again  we  take: 

0?A((S)  H,is))  =  {M/X((S,  H,is))} 

This  situation  captures  the  case  where  an  attempt  is  made  to  dereference  a 
non-existing  selector  field  of  pointer. 

Case  2.  We  consider  the  statement  [x:=y.sel]1  (where  x  ±  y)  in  the  case 
where  there  is  an  abstract  location  ny  such  that  ( y,ny )  £  S'  and  there  is  an 
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abstract  location  ny  ^  n0  such  that  (ny,  sel,ny )  €  H'.  Both  ny  and  ny  will 
be  uniquely  determined  because  of  the  invariants  (and  they  might  be  equal). 
The  abstract  location  ny  will  be  renamed  to  include  the  variable  x  using  the 
function: 

« <■*>  -  { il=jl 

We  shall  then  take 

0fA((S,  H,  is))  =  {(S",  H",is")} 

where  (S',  H',is')  =  killx((S,  H,  is))  and 

S"  =  {(z,h"(nz))\(z,nz)eS'}U{(x,hV(ny))} 

H"  =  {(h^(nv),sel',h^(nw))  |  (nv,sel',nw)  €  H'} 
is"  =  {h% (nz)  |  nz  €  is'} 

The  inclusion  of  (x,h^(nu))  in  S"  reflects  the  assignment.  The  definition  of 
is"  ensures  that  sharing  is  preserved  by  the  operation;  in  particular,  nj/uf*} 
is  shared  in  H"  if  and  only  if  nu  is  shared  in  H'. 

The  effect  of  the  assignment  is  illustrated  in  Figure  2.20  in  the  case  where 
ny  £  is.  As  before  we  assume  that  the  abstract  locations  shown  on  the  figure 
are  distinct  so  in  particular  Y,  V  and  W  are  all  distinct  from  U. 

Case  3.  We  now  consider  the  statement  [x:=y.selY  (where  x  ^  y)  in  the  case 
where  there  is  an  abstract  location  ny  such  that  ( y,ny )  £  S'  and  furthermore 
(ny,  sel,na)  £  H'.  As  before  the  invariants  ensure  that  ny  is  uniquely  deter¬ 
mined.  The  location  n0  describes  the  location  for  y.sel  as  well  as  a  (possibly 
empty)  set  of  other  locations.  We  now  have  to  materialise  a  new  abstract 
location  n^xy  from  n0;  then  will  describe  the  location  for  y.sel  and  n0 
will  continue  to  represent  the  remaining  locations.  Having  introduced  a  new 
abstract  location  we  will  have  to  modify  the  abstract  heap  accordingly. 

This  is  a  potentially  difficult  operation,  so  let  us  consider  the  following  se¬ 
quence  of  assignments: 


[x:=nil]"‘;  [ x:=y.sel]1 ;  [x:=nil]  ' 


! 

(S,  H,  is) 


! 

(S",  H",is") 

(S',  H',  is')  (S'",  H'",  is'") 


Clearly  [x :  =nil]  [x :  =y.sel]e  is  equivalent  to  [x :  -y.sel}1  both  in  terms  of  the 
analysis  and  the  semantics.  Indeed,  (S',H',is')  =  killx({S,  H,  is))  represents 
the  effect  of  removing  the  binding  to  x.  We  are  trying  to  determine  candidate 
shape  graphs  (S",H",is")  holding  after  the  assignment  [x:=y.sel]c  (where 
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x  ^  y)  but  let  us  first  study  our  expectations  to  (S'",  H'",  is'").  It  is  immediate 
that  (S'",  H'",  is'")  =  killx((S",  H",is")).  Furthermore,  the  states  and  heaps 
possible  at  the  point  described  by  (S',  H',  is7)  should  be  the  same  as  those 
possible  at  the  point  described  by  (S'",  H'",  is'").  This  suggests  demanding 
that 

(S'",  H'",  is"')  =  (S',  H',  is') 

which  means  that  killx((S",  H",  is"))  =  (S',  H',  is').  It  is  also  immediate  that 
(XjJifa.})  G  S"  and  that  (ny,sel,Ti{xy)  G  H". 

We  shall  then  take 

<£fA((S,  H,  is))  =  {(S",  H",  is")  |  (S",  H",  is")  is  compatible  A 

kUlx(( S",H",is"))  =  (S',H',is')  A 
(x.njj.})  G  S"  A  ( ny,sel,n{xy )  G  H"} 

where  (S',  H',  is')  =  killx((S,  H,  is)). 

It  is  hopefully  clear  that  we  have  not  missed  any  shape  graphs  (S",  H",  is") 
that  might  be  the  result  of  the  assignment.  What  might  be  a  worry  is  that 
we  have  included  an  excessive  amount  of  irrelevant  shape  graphs.  (Indeed 
producing  all  compatible  shape  graphs  would  be  trivially  sound  but  also 
utterly  useless.)  Although  it  is  possible  to  do  slightly  better  (see  Exercise 
2.22)  we  shall  now  argue  that  there  is  no  excessive  amount  of  imprecision  in 
the  above  definition. 

We  first  establish  that 

S"=S^J{(x,n{x})} 

showing  that  the  abstract  state  is  fully  determined.  Consider  ( z,nz )  G  S". 
If  z  =  x  it  follows  from  the  compatibility  of  (S",H",is")  that  ng  =  nyxy. 
If  z  jz  x  it  follows  from  (x,ri[xy)  G  S"  and  the  compatibility  of  (S",  H",  is") 
that  x  £  Z  and  hence  ( z,nz )  =  ( z,kx(nz ))  (where  kx  is  the  renaming  of  the 
killx  operation).  This  establishes  that  S"  C  S'  U  {(z,ri{x})}.  Next  consider 
( u,nu )  G  S'.  We  know  that  u  /  i  and  x  $  U  from  the  definition  of  S' 
and  from  compatibility  of  (S',  H',  is') .  There  must  exist  (u,  n'y)  G  S"  such 
that  kx(n'u)  =  nxj  but  since  x  ^  u  this  gives  =  nu ■  It  follows  that 
S"  D  S'  U  {(x, ri{x})}  and  we  have  proved  the  required  equality. 

We  next  establish  that 

is'\{n0}  =  is"  \  {n0,n{x}} 

n0  G  is'  iff  7i0  G  is"  V  ri{xy  G  is" 

showing  that 

•  abstract  locations  apart  from  n0  retain  their  sharing  information, 

•  if  n0  is  shared  then  that  sharing  cannot  go  away  but  must  give  rise  to 
sharing  of  at  least  one  of  n0  or  nyxy,  and 
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•  if  rig  is  not  shared  then  no  sharing  can  be  introduced  for  ng  or 

Since  both  (S',  H',  is')  and  (S'',  H",  is")  are  compatible  shape  graphs  it  follows 
that  if  nu  £  S'  then  x  g  U  and  if  nu  £  S"  then  x  g  U  U  {x}  =  U.  Hence 
is'  =  {kx(nu)  |  nu  £  is"}  establishes  is'  \  {ng}  =  is"  \  {ng, n^j}  because 
kx(nu)  =  nu  n$  for  all  nu  £  is"  \  {ng,^*}}.  Furthermore,  ng  G  is"  V 
n{j.}  G  is"  gives  ng  £  is',  and  ng  0  is"  A  nyxy  ^  is"  gives  ng  0  is'.  Thus  we 
have  established  the  required  relationship. 

We  now  turn  to  the  abstract  heap.  We  shall  classify  the  labelled  edges 
(nv,sel' ,nw)  into  four  groups  depending  on  whether  or  not  the  source  or 
target  may  be  one  of  the  nodes  ng  or 

(ny,  sel' ,nw)  is  external  iff  {nv,nw}  D  {ng,^*}}  =  0 
(nv,sel' ,n\v)  is  internal  iff  {ny,nw}  C  {ng,^*}} 

( nv,sel',nw )  is  going-out  iff  ny  G  {ng,^*}}  A  nw  &  {n0,nyxy} 
(ny, sel' ,nw)  is  going-in  iff  ny  #  {ng,n{j.}}  A  nw  £  {n<t>,n{xy} 

We  shall  also  say  that  two  edges  (ny ,  sel',nw)  and  (n'y,  sel1',  n'w)  are  related 
if  and  only  if  kx(ny )  =  kx(n'v),  sel'  =  sel"  and  kx(nw)  =  kx(n'w).  Clearly 
an  external  edge  is  related  only  to  itself. 

Reasoning  as  above  one  can  show  .that 

•  H'  and  H"  have  the  same  external  edges, 

•  each  internal  edge  in  H'  is  related  to  an  internal  edge  in  H"  and  vice 
versa, 

•  each  edge  going-out  in  H'  is  related  to  an  edge  going-out  in  H"  and  vice 
versa,  and 

•  each  edge  going-in  in  H'  is  related  to  an  edge  going-in  in  H"  and  vice 
versa. 

One  consideration  is  that  the  going-in  edge  (ny,sel,n g)  G  H'  should  be 
changed  into  the  going-in  edge  {ny,sel,nrxy)  G  H".  We  clearly  demanded 
that  (ny,sel,n{xy)  G  H"  and  because  (S' ,  H",is")  is  compatible  it  follows 
that  (ny,seZ,ng)  £  H". 

As  a  more  concrete  illustration  consider  the  scenario  in  Figure  2.21.  Here 
neither  ng  nor  nw  is  shared  and  we  assume  that  both  ny  and  nw  are  distinct 
from  ng;  we  also  assume  that  x  ^  y  and  sel 2  ^  sel%.  The  result  of  the 
transfer  function  is  shown  in  Figure  2.22.  First  note  that  the  going-in  edge 
(ny,  seZ,ng)  €  H  is  changed  to  (ny,  sel,  n^})  G  H"  in  all  shape  graphs.  Next 
note  that  the  going-in  edge  labelled  sel  1  can  only  point  to  ng  because  nyxy  is 
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x  — HZEl — i ZU 


(S,  H,  is) 


Figure  2.21:  The  effect  of  [x:=y.sel\l  in  a  special  case  (part  1). 


not  shared  (as  is  not)  and  ny  points  to  The  going-out  edge  labelled 
se/2  can  start  at  both  n@  and  but  it  cannot  do  so  simultaneously  because 
n\y  is  not  shared.  The  internal  edge  labelled  sel$  can  only  point  to  n®  because 
is  not  shared  and  ny  points  to  n^xy,  but  it  can  start  at  both  n$  and 
ri{xy  and  can  even  do  so  simultaneously.  This  explains  why  there  are  only 
six  shape  graphs  in  <^A((S,  H,  is)),  all  of  which  are  clearly  needed. 

Example  2.53  The  statement  .[t:=x.cclr]51  introduced  in  Example  2.52 
is  of  the  form  considered  here:  the"  transfer  function  will  transform  each  of 
the  shape  graphs  of  Shape. (4)  in  Figure  2.16  into  one  of  the  shape  graphs  in 
Figure  2.23.  ■ 

Transfer  function  for  [x.sel:=a]e  where  a  is  of  the  form  n,  ai  opa  a2 
or  nil.  Again  we  consider  a  compatible  shape  graph  (S,  H,  is).  First  assume 
that  there  is  no  nx  such  that  (x,nx)  6  S;  then  x  will  not  point  to  a  cell 
in  the  heap  and  the  statement  will  have  no  effect  on  the  shape  of  the  heap 
so  the  transfer  function  ffA  is  just  the  identity.  Next  assume  that  there 
is  a  (unique)  nx  such  that  (x,nx)  €  S  but  that  there  is  no  ny  such  that 
( nx,sel,nu )  €  H;  then  the  cell  pointed  to  by  sel  does  not  point  to  another 
cell  so  the  statement  will  not  change  the  shape  of  the  heap  and  also  in  this 
case  the  transfer  function  ffA  will  be  the  identity. 

The  interesting  case  is  when  there  are  abstract  locations  nx  and  ny  such  that 
( x,nx )  €  S  and  ( nx,sel,nu )  €  H;  these  abstract  locations  will  be  unique 
because  of  the  invariants.  The  effect  of  the  assignment  will  be  to  remove  the 
triple  (nx ,  sel,nu)  from  H: 

^A((S,H,is))  =  {fci«I.seI((S,H,is))} 
where  killx.  »ei(( S,  H,  is))  =  (S',  H',  is')  is  given  by: 
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Figure  2.22:  The  effect  of  [x:=y.selY  in  a  special  case  (part  2). 


S'  =  S 

H'  =  {(ny,  sel\nw)  |  (ny,  sel1 ,  n\y)  €  H  A  -^(X  =  V  A  sel  =  sel ')} 

{is\{n<y}  if  ny  €  is  A  #into(nu,  H')  <  1  A 
->3 {n$,  sel' ,nu)  €  H' 
is  otherwise 
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Figure  2.23:  Shape  graphs  computed  for  the  list  reversal  program. 


(S,  H,is)  '  (S'.H'.is') 


Figure  2.24:  The  effect  of  [z.se/^nil]*  when  #into(nu,  H')  <1. 


The  sharing  information  is  as  before  except  that  we  may  be  able  to  do  better 
for  the  node  nu  -  we  have  removed  one  of  the  pointers  to  it  and  in  the  case 
where  there  is  at  most  one  pointer  left  and  it  does  not  have  source  the 
corresponding  location  will  be  unshared.  Here  we  write  #into(nu,  H')  for  the 
number  of  pointers  to  nu  in  H'.  This  clause  is  illustrated  in  Figure  2.24. 

Remark.  Again  we  shall  note  that  the  analysis  does  not  incorporate  garbage 
collection:  it  might  be  the  case  that  there  is  only  one  pointer  to  the  abstract 
location  nu  and  that  after  the  assignment  x.sel:= nil  the  corresponding  lo¬ 
cation  will  be  unreachable.  However,  the  abstract  location  may  still  be  part 
of  the  shape  graph.  ■ 

Transfer  function  for  [x.sel:=y]e.  First  assume  that  x  =  y.  The 
statement  is  then  semantically  equivalent  to 


[f :  =y]<1 ;  [x.sel :  =f]<2 ;  [t :  =nil]*3 
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x 


y 


(S,  H,  is) 


(S',  H",  is") 


Figure  2.25:  The  effect  of  [x.sel :  =y]1  when  #into(ny,  H')  <  1. 


where  t  is  a  fresh  variable  and  £i,  i 2  and  1 3  are  fresh  labels.  The  transfer 
function  ffA  is  then  given  by 


The  transfer  functions  ffA  and  ffA  follow  the  pattern  we  have  seen  before 
so  we  shall  concentrate  on  the  clause  for  ffA ,  or  equivalently,  ffA  in  the  case 
where  x±y. 

So  assume  that  x^y  and  that  (S,  H,  is)  is  a  compatible  shape  graph.  It  may 
be  the  case  that  there  is  no  nx  such  that  (x,nx)  £  S  and  in  that  case  the 
transfer  function  will  be  the  identity  since  the  statement  cannot  affect  the 
shape  of  the  heap. 

So  assume  that  nx  satisfies  (x,  nx)  €  S.  The  case  where  there  is  no  ny  such 
that  ( y ,  ny)  €  S  corresponds  to  a  situation  where  the  value  of  y  is  an  integer, 
the  nil-value  or  undefined  and  is  therefore  similar  to  the  case  [x.se/:=nil]*: 

A((S,  H,  is))  =  {killx.sei({S,  H,  is))} 

The  interesting  case  is  when  x  ^  y,  (x, nx)  £  S  and  (y, ny)  e  S.  The  first 
step  will  be  to  remove  the  binding  for  x.sel  and  for  this  we  can  use  the  killx  sel 
function.  The  second  step  will  be  to  establish  the  new  binding.  So  we  take 

0<A((S,  H,  is))  =  {(S",H",is")} 

where  (S',  H',  is')  =  killx.aei(( S,  H,is))  and 

S"  =  S'  (=5) 

H"  =  H'  U  {(nx,  sel,ny)} 

js»  _  f  is' U  {ny}  if  #into(ny,  H')  >  1 
]  is'  otherwise 
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Note  that  the  node  ny  might  become  shared  when  we  add  a  new  pointer  to 
it.  The  effect  of  the  transfer  function  is  illustrated  in  Figure  2.25. 

Example  2.54  This  transfer  function  is  illustrated  by  the  assignment 
[y.cdr:=z]6  of  the  list  reversal  program  of  Example  2.43:  each  of  the  shape 
graphs  of  Shape,  (5)  in  Figure  2.17  are  transformed  into  one  of  the  shape 
graphs  of  Shape,  (6).  ■ 

Transfer  function  for  [x.sel :  =y.sel']e.  This  statement  is  equivalent 
to  the  sequence  of  statement 

[ti^y.sel'Y1',  [x.sel:=t]l2\  [t:=nil]'3 

for  t  being  a  fresh  variable  and  ii,  f2  and  lz  being  fresh  labels.  Thus  the 
transfer  function  ffA  satisfies 

fr=f!3AoftAof?A 

The  transfer  functions  ffA,  ffA  and  /?A  all  follow  the  patterns  we  have  seen 
before  so  this  completes  the  specification  of  the  transfer  function. 

Transfer  function  for  [malloc  p]e.  We  first  consider  the  statement 
[malloc  x\l  where  we  have  to  remove  the  binding  for  x  and  then  introduce  a 
new  (unshared)  location  pointed  to  by  x .  Thus  we  define 

0/A((S,  H,is))  =  {-(-S'  U  {(*,»{,})},  H',  is')} 

where  (S',H',is')  =  killx( S,  H,is). 

The  statement  [malloc  (x.se/)]<  is  equivalent  to  the  sequence 
[malloc  f]'1 ;  [x.sel :  =t]/a ;  [f :  =nil]'3 


where  t  is  a  fresh  variable  and  f2  and  (3  are  fresh  labels.  The  transfer 
function  ffA  is  then 

f!A  =  f!A°flA°flA 

The  transfer  functions  ffA,  ffA  and  ffA  all  follow  the  patterns  we  have  seen 
before  so  this  completes  the  specification  of  the  transfer  function. 


Concluding  Remarks 

Data  Flow  Analysis  for  imperative  languages.  As  mentioned 
in  the  beginning  of  this  chapter,  Data  Flow  Analysis  has  a  long  tradition. 
Most  compiler  textbooks  contain  sections  on  optimisation  which  mainly  dis¬ 
cuss  Data  Flow  Analyses  and  their  implementation  [2,  39, 141].  The  emphasis 
in  these  books  is  often  on  practical  implementations  of  data  flow  analyses.  A 
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classic  textbook  which  provides  a  more  theoretical  treatment  of  the  subject 
is  by  Hecht  [52];  the  book  contains  a  detailed  discussion  of  the  four  exam¬ 
ple  Data  Flow  Analyses  in  Section  2.1,  and  also  presents  a  more  traditional 
treatment  of  Monotone  Frameworks  based  on  the  use  of  semi-lattices  as  well 
as  a  number  of  algorithms  (see  Chapter  6  for  a  more  thorough  treatment  of 
algorithms).  Marlowe  and  Ryder  [78]  provide  a  survey  of  data  flow  frame¬ 
works.  Steffen  [129]  and  Schmidt  [117]  express  data  flow  analyses  using  modal 
logic  (rather  than  equations)  thereby  opening  up  for  using  model  checking 
techniques  for  program  analysis. 

The  examples  presented  in  Section  2.1  are  fairly  standard.  Alternative  treat¬ 
ments  of  this  material  can  be  found  in  any  of  the  books  already  cited.  The 
examples  may  all  be  represented  as  Bit  Vector  Frameworks  (see  Exercise  2.9): 
the  lattice  elements  may  be  represented  by  a  vector  of  bits  and  the  lattice  op¬ 
erations  efficiently  implemented  as  boolean  operations.  The  method  used  in 
Section  2.2  to  prove  the  correctness  of  the  Live  Variables  Analysis  is  adapted 
from  [84].  The  notion  of  faint  variables,  introduced  in  Exercise  2.4,  was  first 
introduced  by  Giegerich,  Moncke  and  Wilhelm  [49], 

The  use  of  semi-lattices  in  Data  Flow  Analysis  was  first  proposed  in  [72],  The 
notion  of  Monotone  Frameworks  is  due  to  Kam  and  Ullman  [70].  These  early 
papers,  and  much  of  the  later  literature,  use  the  dual  notions  (meets  and 
maximal  fixed  points)  to  our  presentation.  Kam  and  Ullman  [70]  prove  that 
the  existence  of  a  general  algorithm  to  compute  MOP  solutions  would  imply 
the  decidability  of  the  Modified  Post  Correspondence  Problem  [57].  Cousot 
and  Cousot  [27]  model  abstract  program  properties  by  complete  semi-lattices 
in  their  paper  on  Abstract  Interpretation  (see  Chapter  4). 

We  have  associated  transfer  functions  with  elementary  blocks.  It  would  be 
possible  to  associate  transfer  functions  with  flows  instead  as  e.g.  in  [113]. 
These  two  approaches  have  equal  power:  to  go  from  the  first  to  the  second, 
the  transfer  functions  may  be  moved  from  the  blocks  to  their  outgoing  flows; 
to  go  from  the  second  to  the  first,  we  can  introduce  artificial  blocks.  In  fact 
artificial  blocks  can  be  avoided  as  shown  in  Exercise  2.11. 

Most  of  the  papers  that  we  have  cited  so  far  concentrate  on  intraprocedural 
analysis.  An  early,  and  influential,  paper  on  interprocedural  analysis  is  [120] 
that  studies  two  approaches  to  establishing  context.  One  is  based  on  call 
strings  and  expresses  aspects  of  the  dynamic  calling  context;  our  presentation 
is  inspired  by  [139].  The  other  is  based  on  data  and  shares  some  of  the 
aims  of  assumption  sets  [74,  106,  112];  the  technical  formulation  is  different 
because  [120]  obtains  the  effect  by  calculating  the  transfer  functions  for  the 
call  statement.  Most  of  the  subsequent  papers  in  the  literature  can  be  seen 
as  variations  and  combinations  over  this  theme;  a  substantial  effort  in  this 
direction  may  be  found  in  [34]. 
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Pointer  analysis.  There  is  an  extensive  literature  on  the  analysis  of 
alias  problems  for  languages  with  pointers.  Following  [46]  we  can  distinguish 
between  analyses  of  pointers  to  (1)  statically  allocated  data  (typically  on 
the  stack)  and  (2)  dynamically  allocated  data  (typically  in  the  heap).  The 
analysis  of  pointers  to  statically  allocated  data  is  the  simplest:  typically  the 
data  will  have  compile-time  names  and  the  analysis  result  can  be  presented 
as  a  set  of  points-to  pairs  of  the  form  (p,  x)  meaning  that  the  pointer  p  points 
to  the  data  a:  or  as  alias  pairs  of  the  form  (*p,  x)  meaning  that  *p  and  x  are 
aliased.  Analyses  in  this  category  include  [36,  75,  112,  142,  127,  119]. 

The  analysis  of  dynamically  allocated  data  is  more  complicated  since  the 
objects  of  interest  are  inherently  anonymous.  The  simplest  analyses  [28, 
45]  study  the  connectivity  of  the  heap:  they  attempt  to  split  the  heap  into 
disjoint  parts  and  do  not  keep  any  information  about  the  internal  structure 
of  the  individual  parts.  These  analyses  have  been  found  quite  useful  for  many 
applications. 

The  more  complex  analyses  of  dynamically  allocated  data  give  more  precise 
information  about  the  shape  of  the  heap.  A  number  of  approaches  use  graphs 
to  represent  the  heap.  A  main  distinction  between  these  approaches  is  how 
they  map  a  heap  of  potentially  unbounded  size  to  a  graph  of  bounded  size: 
some  bounds  the  length  of  paths  in  the  heap  [64, 130],  others  merge  heap  cells 
created  at  the  same  program  point  [65,  20],  and  yet  others  merge  heap  cells 
that  cannot  be  kept  apart  by  the  set  of  pointer  variables  pointing  to  them 
[114,  115].  Another  group  of  analyses  obtain  information  about  the  shape 
of  the  heap  by  more  directly  approximating  the  access  paths.  Here  a  main 
distinction  is  the  kind  of  properties  of  the  access  paths  that  are  recorded: 
some  focus  on  simple  connectivity  properties  [46],  others  use  some  limited 
form  of  regular  expressions  [76],  and  yet  others  use  monomial  relations  [35]. 

The  analysis  presented  in  Section  2.6  is  based  on  the  work  of  Sagiv,  Reps 
and  Wilhelm  [114,  115].  In  contrast  to  [114,  115]  it  uses  sets  of  compatible 
shape  graphs;  [114,  115]  merges  sets  of  compatible  shape  graphs  into  a  single 
summary  shape  graph  and  then  use  various  mechanisms  for  extracting  parts 
of  the  individual  compatible  shape  graphs  and  in  this  way  an  exponential 
factor  in  the  cost  of  the  analysis  can  be  avoided.  The  sharing  component  of 
the  shape  graphs  is  designed  to  detect  list-like  properties;  it  can  be  replaced 
by  other  components  detecting  other  shape  properties  [116]. 

Static  Single  Assignments.  Prior  to  analysis,  many  modern  com¬ 
pilers  perform  a  source-to-source  transformation  which  produces  a  program  in 
static  single  assignment  (SSA)  form.  In  SSA  form  there  is  a  single  assignment 
for  each  name;  this  is  achieved  by  variable  renaming.  The  transformation  also 
introduces  new  assignments  which  combine  the  results  from  several  assign¬ 
ments  (using  the  so-called  <p  functions)  at  certain  points.  Uses  of  names  on 
the  right  hand  side  of  an  assignment  refer  to  the  result  of  a  unique  assignment 
of  one  of  the  previous  two  forms.  The  advantage  of  transforming  the  pro- 
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gram  in  this  way  is  that  some  analyses  become  simpler  or  more  effective.  An 
efficient  algorithm  for  computing  SSA  form  was  introduced  in  [32].  The  first 
algorithm  gives  conservative  results  for  arrays;  [73]  presents  a  new  approach 
to  array  SSA  form  that  captures  precise  element-level  data  flow  information 
for  array  variables. 

Data  Flow  Analysis  for  other  language  paradigms.  The 

analysis  techniques  that  we  have  studied  assume  the  existence  of  some  rep¬ 
resentation  of  the  flow  of  control  in  the  program.  For  the  class  of  imperative 
languages  that  we  have  studied,  it  is  relatively  easy  to  determine  this  control 
flow  information.  For  many  languages,  for  example  functional  programming 
languages,  this  is  not  the  case.  The  next  chapter  presents  techniques  for  de¬ 
termining  control  flow  information  for  such  languages  and  shows  how  Data 
Flow  Analysis  can  be  integrated  with  Control  Flow  Analysis. 

The  techniques  we  have  presented  can  be  applied  directly  to  other  language 
paradigms.  Two  examples  are  in  object-oriented  programming  and  a  commu¬ 
nicating  processes  language.  In  both  cases  the  authors  describe  their  analyses 
by  data  flow  equations.  Vitek,  Horspool  and  Uhl  [139]  present  an  analysis  for 
object-oriented  languages  which  determines  classes  of  objects  and  their  life¬ 
times.  Their  analysis  is  an  interprocedural  analysis  that  uses  a  graph-based 
representation  of  the  memory  as  data  flow  values.  Reif  and  Smolka  [109]  ap¬ 
ply  Data  Flow  Analysis  techniques  to  distributed  communicating  processes  to 
detect  unreachable  code  and  to  determine  the  values  of  program  expressions. 
They  apply  their  analysis  to  a  language  with  asynchronous  communication. 
Their  reachability  analysis  is  based  on  an  algorithm  that  builds  a  spanning 
tree  for  each  process  flow  graph  and  links  matching  transmits  and  receives 
between  processes.  They  construct  a  Monotone  Framework  for  determining 
value  sets. 

We  refer  to  the  Concluding  Remarks  of  Chapter  6  for  a  discussion  of  systems 
implementing  data  flow  analysers. 


Mini  Projects 

Mini  Project  2.1  ud-  and  du-chains 

The  aim  of  this  mini  project  is  to  develop  a  more  thorough  understanding  of 
the  concepts  of  ud-  and  du-chains  introduced  in  Subsection  2.1.5. 

1.  The  function  ud  is  specified  in  terms  of  definition  clear  paths,  whilst 
UD  re-uses  functions  introduced  for  the  Reaching  Definitions  and  Live 
Variables  Analyses.  Prove  that  the  two  functions  compute  the  same 
information. 
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Figure  2.26:  du-and  ttd-chains. 


2.  DU  can  be  defined  by  analogy  with  UD.  Starting  from  the  definition  of 
du ,  develop  an  equational  definition  of  DU  and  verify  its  correctness. 

3.  A  Constant  Propagation  Analysis  is  presented  in  Subsection  2.3.3;  an 
alternative  approach  would  be  to  use  du-  and  ud-chains.  Suppose  there 
is  a  block  [x  :=  ri\*  that  assigns  a  constant  n  to  a  variable  x.  By 
following  the  du-chain  it  is  possible  to  find  all  blocks  using  the  variable 
x.  It  is  only  safe  to  replace  A  use  of  x  by  the  constant  n  in  a  block  l' 
if  all  other  definitions  that  reach  i'  also  assign  the  same  constant  n  to 
x.  This  can  be  determined  by  using  the  ud-chain.  This  is  illustrated 
in  Figure  2.26.  Considering  the  program  of  Example  2.12,  Constant 
Folding  (followed  by  Dead  Code  Elimination )  can  be  used  to  produce 
the  following  program: 

(if  [z=3]3  then  [z:=0]4  else  [z:=3]5);  [y:=3]6;  [x:=3+z]7 
Develop  a  formal  description  of  this  analysis.  ■ 

Mini  Project  2.2  Correctness  of  Reaching  Definitions 

The  aim  of  this  mini  project  is  to  prove  the  correctness  of  Reaching  Definitions 
with  respect  to  the  notion  of  semantic  reaching  definitions  introduced  in 
Section  1.5.  To  get  a  precise  definition  of  the  set  of  traces  of  interest  we  shall 
begin  by  introducing  a  so-called  instrumented  semantics:  an  extension  of  a 
more  traditional  semantics  that  keeps  track  of  additional  information  that  is 
mainly  of  interest  for  the  program  analysis. 

The  instrumented  semantics  has  transitions  of  the  forms: 


* 


(5,  cr,  tr)  ->  (a1,  tr1)  and  ( S ,  or,  tr)  -4  (S',  a1,  tr') 
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[ass]  ([x  :=  a)1,  a,  tr)  -4  (a[x  >-4  ^4|ajcr],  tr  :  (x,  t)) 
[sfcip]  ([skip]*,  a,  tr)  -4  (a,  tr) 


(Si, a,  tr)  -4  ( S[,a',tr ') 
(Si;S2,or,tr)  -4  (S[;S2,<t',  tr1) 


[seq2] 

[*A] 

W2] 


{Si, a,  tr)  -4  ( o'  ,tr ') 

(5x;52,ct,  fr)  -4  (S2,u',tr') 

(if  [6]*  then  S\  else  52,  <7,  tr)  -4  (Si,  a,  tr) 
(if  [6]*  then  S\  else  52,<7,  tr)  -4  (S2,<t,  tr) 


if  5[6]<r  =  true 
if  B\b\a  =  false 


[ur/ii]  (while  [6]/  do  5,  a,  tr)  -4  ((5;  while  [b]*  do  S),a,  tr) 

if  B[b]a  =  true 

[w/12]  (while  [6]*  do  5,  <7,  tr)  -4  (a,  tr)  if  B\b\a  =  false 


Table  2.10:  The  instrumented  semantics  of  While. 

All  configurations  include  a  trace  -tr  g  Trace  =  (Var  x  Lab)*  that  records 
the  elementary  block  in  which  a1  variable  is  being  assigned.  The  detailed 
definition  of  the  instrumented  semantics  is  given  in  Table  2.10. 

Given  a  program  5*  and  an  initial  state  <7*  g  State  it  is  natural  to  construct 
the  trace 

fr*  =  ((xi,?),---,(xn,?)) 

where  Xi ,  •  •  • ,  x„  are  the  variables  in  5*  and  to  consider  the  finite  derivation 
sequence: 

(5*,a*,fr*)  -4*  (o',  tr') 

Intuitively,  there  should  be  a  similar  derivation  sequence  (5*,  0*)  -4*  a'  in  the 
Structural  Operational  Semantics.  Similar  remarks  apply  to  infinite  deriva¬ 
tion  sequences. 

As  in  Section  2.2  we  shall  study  the  constraint  system  RD-  (5*)  corresponding 
to  the  equation  system  RD=(5*).  Let  reach  be  a  collection  of  functions: 

reachentry ,  reachexn  :  Lab*  -4  T’(Var*  x  Lab*) 

We  say  that  reach  solves  RD-(5),  and  write 

reach  j=  RD-(5) 


if  the  functions  satisfy  the  constraints;  similarly  for  reach  j=  RD  (5). 
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1.  Formulate  and  prove  results  corresponding  to  Lemmas  2.15,  2.16  and 
2.18. 

The  correctness  relation  ~  will  relate  traces  tr  £  Trace  to  the  information 
obtained  by  the  analysis.  Let  Y  C  'P(Var*  x  Lab*)  and  define 

tr  ~  Y  iff  Vx  £  Var*  :  (x,  SRD(£r)(i))  £  Y 

meaning  that  Y  contains  at  least  the  semantically  reaching  definitions  ob¬ 
tained  from  the  trace  tr  by  the  function  SRD  introduced  in  Section  1.5. 

2.  Formulate  and  prove  results  corresponding  to  Lemma  2.20,  Theorem 

2.21  and  Corollary  2.22.  ■ 

Mini  Project  2.3  A  Prototype  Implementation 

In  this  mini  project  we  shall  implement  one  of  the  program  analyses  consid¬ 
ered  in  Section  2.1.  As  implementation  language  we  shall  choose  a  functional 
language  such  as  Standard  ML  or  Haskell.  We  can  then  define  a  suitable 
data  type  for  While  programs  as  follows: 

type  var  =  string 

type  label  =  int 

datatype  aexp  =  Var  of  war j-Const  of  int 

|  Op  of  string  *  aexp  *  aexp 

and  bexp  =  True  |  False 

|  Not  of  bexp  |  Boolop  of  string  *  bexp  *  bexp 
|  Relop  of  string  *  aexp  *  aexp 

datatype  stat  =  Assign  of  var  *  aexp  *  label  |  Skip  of  label 

|  Seq  of  stat  *  stat  |  If  of  bexp  *  label  *  stat  *  stat 
|  While  of  bexp  *  label  *  stat 

Now  proceed  as  follows: 

1.  Implement  the  operations  init,  final,  fiow,  flow*1  and  blocks. 

2.  Generate  the  data  flow  equations  for  the  Live  Variables  Analysis  of 
Subsection  2.1.4. 

3.  Solve  the  data  flow  equations;  the  function  should  be  based  on  the 
algorithm  of  Section  2.4. 


For  the  more  ambitious:  generalise  your  program  to  accept  an  instance  of  a 
Monotone  Framework  as  input.  ■ 
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Exercises 

Exercise  2.1  Formulate  data  flow  equations  for  the  Reaching  Definitions 
Analysis  of  the  program  studied  in  Example  1.1  of  Chapter  1  and  in  particular 
define  the  appropriate  gen  and  kill  functions.  ■ 

Exercise  2.2  Consider  the  following  program: 

[x :  =l]x;  (while  [y>0]2  do  [x:=x-l]3);  [x:=2]4 

Perform  a  Live  Variables  Analysis  for  this  program  using  the  equations  of 
Section  2.1.4.  ■ 

Exercise  2.3  A  modification  of  the  Available  Expressions  Analysis  de¬ 
tects  when  an  expression  is  available  in  a  particular  variable:  a  non-trivial 
expression  a  is  available  in  a;  at  a  label  i  if  it  has  been  evaluated  and  assigned 
to  x  on  all  paths  leading  to  l  and  if  the  values  of  x  and  the  variables  in  the 
expression  have  not  changed  since  then.  Write  down  the  data  flow  equations 
and  any  auxiliary  functions  for  this  analysis.  ■ 


Exercise  2.4  Consider  the  following  program: 

[x :  =l]1 ;  fx-:  =x-l]2;  [x :  =2]3 

Clearly  x  is  dead  at  the  exits  from  2  and  3.  But  x  is  live  at  the  exit  of  1  even 
though  its  only  use  is  to  calculate  a  new  value  for  a  variable  that  turns  out  to 
be  dead.  We  shall  say  that  a  variable  is  a  faint  variable  if  it  is  dead  or  if  it  is 
only  used  to  calculate  new  values  for  faint  variables;  otherwise  it  is  strongly 
live.  In  the  example  x  is  faint  at  the  exits  from  1,  2  and  3.  Define  a  Data 
Flow  Analysis  that  detects  strongly  live  variables.  (Hint:  For  an  assignment 
[x  :=  a]*  the  definition  of  ft(l)  should  be  by  cases  on  whether  x  is  in  l  or 
not.)  ■ 


Exercise  2.5  A  basic  block  is  often  taken  to  be  a  maximal  group  of  state¬ 
ments  such  that  all  transfers  to  the  block  are  to  the  first  statement  in  the 
group  and,  once  the  block  has  been  entered,  all  statements  in  the  group  are 
executed  sequentially.  In  this  exercise  we  shall  consider  basic  blocks  of  the 
form 

[xi  :=  Ui  j  *  *  * ;  xn  :=  an ;  B] 

where  n  >  0  and  B  is  x  :=  a,  skip  or  b.  Reformulate  the  analyses  of  Section 
2.1  for  this  more  general  notion  of  basic  block.  ■ 
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Exercise  2.6  Consider  the  analyses  Available  Expressions  and  Reaching 
Definitions.  Which  of  the  equations  make  sense  for  programs  that  do  not 
have  isolated  entries  (and  how  can  this  be  improved)?  Similarly,  which  of 
the  equations  for  Very  Busy  Expressions  and  Live  Variables  make  sense  for 
programs  that  do  not  have  isolated  exits  (and  how  can  this  be  improved)? 
(Hint:  See  the  beginning  of  Section  2.3.)  ■ 

Exercise  2.7  Consider  the  correctness  proof  for  the  Live  Variables  Anal¬ 
ysis  in  Section  2.2.  Give  a  compositional  definition  of  LV=(-  •  •)  for  a  label 
consistent  statement  using 

LV=([skip]<)  =  {LVextt(<?)  =  LVentrv(£)} 

as  one  of  the  clauses  and  observe  that  a  similar  development  is  possible  for 
LV-(-  ■  •).  Give  a  formal  definition  of  live  j=  C  where  C  is  a  set  of  equalities 
or  inclusions  as  might  have  been  produced  by  LV=(S)  or  LV-(S). 

Prove  that  {five  |  live  |=  LV-(S)}  is  a  Moore  family  in  the  sense  of  Appendix 
A  (with  fl  being  f)  and  determine  whether  or  not  a  similar  result  holds  for 
{ live  |  live  f=  LV=(5)}.  ■ 

Exercise  2.8  Show  that  Constant  Propagation  is  a  Monotone  Framework 
with  the  set  J~cp  as  defined  in  Section  2.3.3.  ■ 

Exercise  2.9  A  Bit  Vector  Framework  is  a  special  instance  of  a  Monotone 
Framework  where 

•  L  =  {V(D),  C)  for  some  finite  set  D  and  where  C  is  either  C  or  D,  and 

•  T  =  {/  :  V(D)  ->  V{D)  |  3Y},Y}CD:VYCD: 

f(Y)  =  {YC\Y})UYj} 

Show  that  the  four  classical  analyses  of  Section  2.1  are  Bit  Vector  Frame¬ 
works.  Show  that  all  Bit  Vector  Frameworks  are  indeed  Distributive  Frame¬ 
works.  Devise  a  Distributive  Frameworks  that  is  not  also  a  Bit  Vector  Frame¬ 
work.  ■ 

Exercise  2.10  Consider  the  Constant  Propagation  Analysis  of  Section 
2.3.3  and  the  program 

(if  [H1  then  [x:=-l]2;  [y:=l]3  else  [x:=l]4;  [y:=-l]5);  [2:=x*y]6 
Show  that  MFP,( 6)  differs  from  MOP,  (6).  m 
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Exercise  2.11  In  our  formulation  of  Monotone  Frameworks  we  associate 
transfer  functions  with  basic  blocks.  In  a  statement  of  the  form 

if  [&]*  then  Si  else  S2 

this  prevents  us  from  using  the  result  of  the  test  to  pass  different  information 
to  Si  and  S2;  as  an  example  suppose  that  x  is  known  to  be  positive  or  negative 
and  that  b  is  the  test  x>0,  then  x  is  always  positive  at  the  entry  to  Si  and 
always  negative  at  the  entry  to  S2.  To  remedy  this  deficiency  consider  writing 
[6]*  as  where  i\  corresponds  to  b  evaluating  to  true  and  £2  corresponds 

to  b  evaluating  to  false.  Make  the  necessary  changes  to  the  development  in 
Sections  2.1  and  2.3.  (Begin  by  considering  forward  analyses.)  ■ 

Exercise  2.12  Consider  one  of  the  analyses  Available  Expressions,  Very 
Busy  Expressions  and  Live  Variables  Analysis  and  perform  a  complexity  anal¬ 
ysis  in  the  manner  of  Example  2.30.  ■ 

Exercise  2.13  Let  F  be  flow(5*)  and  E  be  {init  (■?*)}  for  a  label  consis¬ 
tent  program  5*.  Show  that 

W  €  Lab*  :  path0(£)  ^  0 

Prove  a  similar  result  when  F  is  flow^S*)  and  E  is  final(S+).  m 

Exercise  2.14  In  a  Detection  of  Signs  Analysis  one  models  all  negative 
numbers  by  the  symbol  zero  by  the  symbol  0,  and  all  positive  numbers 
by  the  symbol  +.  As  an  example,  the  set  {—2,  — 1, 1}  is  modelled  by  the  set 
{-,+},  that  is  an  element  of  the  powerset  T’({-,0,+}). 

Let  5*  be  a  program  and  Var*  be  the  finite  set  of  variables  in  S*.  Take 
L  to  be  Var*  ->  ^({-,0,+})  and  define  an  instance  ( L,F,F,E,i,f '.)  of  a 
Monotone  Framework  for  performing  Detection  of  Signs  Analysis. 

Similarly,  take  L'  to  be  V{W ar*  x  {-,  0,  +})  and  define  an  instance  ( L F',  F', 
E',  1',  f!)  of  a  Monotone  Framework  for  Detection  of  Signs  Analysis.  Is  there 
any  difference  in  the  precision  obtained  by  the  two  approaches?  ■ 

Exercise  2.15  In  the  previous  exercise  we  defined  a  Detection  of  Signs 
Analysis  that  could  not  record  the  interdependencies  between  signs  of  vari¬ 
ables  (e.g.  that  two  variables  x  and  y  always  will  have  the  same  sign);  this  is 
sometimes  called  an  independent  attribute  analysis.  In  this  exercise  we  shall 
consider  a  variant  of  the  analysis  that  is  able  to  record  the  interdependencies 
between  signs  of  variables;  this  is  sometimes  called  a  relational  analysis.  To  do 
so  take  L  to  be  P(Var*  — ►  {-,  0,  +})  and  define  an  instance  (L,  F .  F,  E,  1,  f.) 
of  a  Monotone  Framework  for  performing  Detection  of  Signs  Analysis.  Con¬ 
struct  an  example  showing  that  the  result  of  this  relational  analysis  may  be 
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more  informative  than  that  of  the  independent  attribute  analysis.  The  dis¬ 
tinction  between  independent  attribute  methods  and  relational  methods  is 
further  discussed  in  Chapter  4.  ■ 

Exercise  2.16  The  interprocedural  analysis  using  bounded  call  strings 
uses  contexts  to  record  the  last  k  call  sites.  Reformulate  the  analysis  for  a 
notion  of  context  that  records  the  last  k  distinct  call  sites.  Discuss  whether 
or  not  this  analysis  is  useful  for  distinguishing  between  the  call  of  a  procedure 
and  subsequent  recursive  calls.  ■ 

Exercise  2.17  Consider  the  Fibonacci  program  of  Example  2.33  and  the 
Detection  of  Signs  Analysis  of  Exercise  2.15  and  Example  2.36.  Construct 
the  data  flow  equations  corresponding  to  using  large  and  small  assumption 
sets,  respectively.  ■ 

Exercise  2.18  Choose  one  of  the  four  classical  analyses  from  Section  2.1 
and  formulate  it  as  an  interprocedural  analysis  based  on  call  strings.  (Hint: 
Some  may  be  easier  than  others.)  ■ 

Exercise  2.19  Extend  the  syntax  of  programs  to  have  the  form 
begin  Dk\  input  x\  5*;  output  y  end 

so  that  it  maps  integers  to  integers  rather  than  states  to  states.  Consider  the 
Detection  of  Signs  Analysis  and  define  the  transfer  functions  for  the  input 
and  output  statements.  ■ 

Exercise  2.20  Consider  extending  the  procedure  language  such  that  pro¬ 
cedures  can  have  multiple  call-by- value,  call-by-result  and  call-by- value-result 
parameters  as  well  as  local  variables  and  reconsider  the  Detection  of  Signs 
Analysis.  How  should  one  define  the  transfer  functions  associated  with  pro¬ 
cedure  call,  procedure  entry,  procedure  exit,  and  procedure  return?  ■ 

Exercise  2.21  In  the  Shape  Analysis  of  Section  2.6  work  out  direct  def¬ 
initions  of  the  transfer  functions  for  elementary  statements  of  the  forms 
[x:=x.sel]1,  \x.sel:=x}1,  [x.sel:=x.sel'Y  and  [malloc  (x.sel)]*.  ■ 

Exercise  2.22  Consider  Case  3  in  the  definition  of  the  transfer  function 
for  [x:=y.se/]*  (where  x  ^  y)  in  the  Shape  Analysis.  Make  a  careful  analy¬ 
sis  of  internal,  going-in  and  going-out  edges  and  determine  whether  or  not 
some  of  the  shape  graphs  (S",H",is")  in  <^>fA((S,  H,  is))  can  be  removed  by 
placing  stronger  demands  on  the  edges  in  H"  compared  to  those  in  H'  (where 
(S',  H',  is')  =  killx((S,  H,  is))).  ■ 
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Exercise*  2.23  The  Shape  Analysis  as  presented  in  Section  2.6  does  not 
take  garbage  collection  into  account.  Modify  the  Structural  Operational  Se¬ 
mantics  of  the  pointer  language  to  perform  garbage  collection  and  subse¬ 
quently  modify  the  analysis  to  reflect  this.  ■ 

Exercise*  2.24  The  use  of  a  single  abstract  summary  location  leads  to  a 
certain  amount  of  inaccuracy  in  the  Shape  Analysis.  A  more  accurate  anal¬ 
ysis  could  associate  allocation  sites  with  the  abstract  locations.  An  abstract 
location  would  then  have  the  form  where  i  is  an  allocation  site  (a  label 
of  a  malloc-statement)  and  AT  is  a  set  of  variables  as  before.  Develop  the 
transfer  functions  for  the  new  analysis.  ■ 


Chapter  3 


Control  Flow  Analysis 


In  this  chapter  we  present  the  technique  of  Control  Flow  Analysis  using 
a  simple  functional  language,  Fun.  We  begin  by  presenting  an  abstract 
specification  of  the  analysis  and  then  study  its  theoretical  properties:  it  is 
correct  with  respect  to  a  Structural  Operational  Semantics  and  it  can  be 
used  to  analyse  all  programs.  This  specification  of  the  analysis  does  not 
immediately  lend  itself  to  an  efficient  algorithm  for  computing  a  solution  so 
we  proceed  by  developing  first  a  syntax  directed  specification  and  then  a 
constraint  based  formulation  and -finally  we  show  how  the  constraints  can 
be  solved.  We  conclude  by  illustrating  how  the  precision  of  the  analysis  can 
be  improved  by  combining  it  with  Data  Flow  Analysis  and  by  incorporating 
context  information  thereby  linking  up  with  the  development  of  the  previous 
chapter. 


3.1  Abstract  O-CFA  Analysis 

In  Chapter  2  we  saw  how  properties  of  data  could  be  propagated  through  a 
program.  In  developing  the  specification  we  relied  on  the  ability  to  identify  for 
each  program  fragment  all  the  possible  successor  (and  predecessor)  fragments 
-  via  the  operator  flow  (and  flow**)  and  the  interprocedural  flow  inter-flow* 
(and  inter- flow?) .  The  usefulness  of  the  resulting  specification  was  due  to  the 
number  of  successors  and  predecessors  being  small  (usually  just  one  or  two 
except  for  procedure  exits).  This  is  a  typical  feature  of  imperative  programs 
without  procedures  but  it  usually  fails  for  more  general  languages,  whether 
imperative  languages  with  procedures  as  parameters,  functional  languages, 
or  object-oriented  languages.  In  particular,  the  interprocedural  technique^  of 
Section  2.5  provide  a  solution  for  the  simpler  cases  where  the  program  text 
allows  one  to  limit  the  number  of  successors,  as  is  the  case  when  a  proce- 
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Jure  call  is  performed  by  explicitly  mentioning  the  name  of  the  procedure. 
However,  these  techniques  are  not  powerful  enough  to  handle  the  dynamic 
dispatch  problem  where  variables  can  denote  procedures.  In  Section  1.4  we 
illustrated  this  by  the  functional  program 

let  f  =  fn  x  =>  x  1; 
g  =  fn  y  =>  y+2; 
h  =  fn  z  =>  z+3 
in  (f  g)  +  (f  h) 

where  the  function  application  x  1  in  the  body  of  f  will  transfer  control 
to  the  body  of  the  function  x,  and  here  it  is  not  so  obvious  what  program 
fragment  this  actually  is,  since  x  is  the  formal  parameter  of  f .  The  Control 
Flow  Analysis  of  the  present  chapter  will  provide  a  solution  to  the  dynamic 
dispatch  problem  by  determining  for  each  subexpression  a  hopefully  small 
number  of  functions  that  it  may  evaluate  to;  thereby  it  will  determine  where 
the  flow  of  control  may  be  transferred  to  in  the  case  where  the  subexpression 
is  the  operator  of  a  function  application.  In  short,  Control  Flow  Analysis 
will  determine  the  interprocedural  flow  information  ( inter-Bow *  or  IF)  upon 
which  the  development  of  Section  2.5  is  based. 

Syntax  of  the  Fun  language.  For  the  main  part  of  this  chapter 
we  shall  concentrate  on  a  small  functional  language:  the  untyped  lambda 
calculus  extended  with  explicit  operators  for  recursion,  conditional  and  local 
definitions.  The  purpose  of  the  Control  Flow  Analysis  will  be  to  compute 
for  each  subexpression  the  set  of  functions  that  it  could  evaluate  to,  and  to 
express  this  it  is  important  that  we  are  able  to  label  all  program  fragments. 
We  shall  be  very  explicit  about  this:  a  program  fragment  with  a  label  is 
called  an  expression  whereas  a  program  fragment  without  a  label  is  called  a 
term.  So  we  use  the  following  syntactic  categories: 

e  6  Exp  expressions  (or  labelled  terms) 
t  e  Term  terms  (or  unlabelled  expressions) 

We  assume  that  a  countable  set  of  variables  is  given  and  that  constants 
(including  the  truth  values),  binary  operators  (including  the  usual  arithmetic, 
boolean  and  relational  operators)  and  labels  are  left  unspecified: 


f,x 

€ 

Var 

variables 

c 

€ 

Const 

constants 

op 

€ 

Op 

binary  operators 

t 

€ 

Lab 

labels 

The  abstract  syntax  of  the  language  is  now  given  by: 
e  ::=  tl 

t  ::=  c  |  x  |  fn  x  =>  eo  |  fun  f  x  =>  e o  |  ei  e% 

|  if  eo  then  e\  else  e<i  |  let  x  =  e\  in  e2  |  e\  op  e-i 


r 


3.1  Abstract  O-CFA  Analysis 


141 


Here  fn  x  =>  eo  is  a  function  definition  (or  function  abstraction)  whereas 
fun  f  x  =>  e o  is  a  recursive  variant  of  f n  x  =>  eo  where  all  free  occurrences  of 
/  in  eo  refer  to  fun  f  x  =>  e o  itself.  The  construct  let  x  =  e\  in  e2  is  a  non¬ 
recursive  local  definition  that  semantically  is  equivalent  to  (fn  x  =>  e2)(ei). 
As  usual  we  shall  use  parentheses  to  disambiguate  the  parsing  whenever 
needed.  Also  we  shall  assume  throughout  that  in  all  occurrences  of  fun  /  x  => 
eo,  /  and  x  are  distinct  variables. 

We  shall  need  the  notion  of  free  variables  of  expressions  and  terms  so  we 
define  the  function 

FV :  (Term  U  Exp)  -4  'P(Var) 

in  the  following  standard  way.  The  abstractions  f n  x  =>  eo  and  fun  /  x  =>  e0 
contain  binding  occurrences  of  variables  so  FV( f  n  x  =>  eo)  =  FV(eu)\{a:}  and 
similarly  FV(fun  /  x  =>  e0)  =  FV(e0)  \  {f,x}.  Similarly,  let  x  =  ex  in  e2 
contains  a  binding  occurrence  of  x  so  we  have  FV(let  x  =  e\  in  e2)  = 
FV(e i)  U  (FV(e2)  \  {a;})  reflecting  that  free  occurrences  of  x  in  ei  are  bound 
outside  the  construct.  The  remaining  clauses  for  FV  are  straightforward. 

Example  3.1  The  functional  program  (fn  x  =>  x)  (fn  y  =>  y)  consid¬ 
ered  in  Section  1.4  is  now  written  as: 

((fn  x  =>  x1)2  (fn  y  =>  y3)4)5 

Compared  with  the  notation  of  Example  1.2  we  have  omitted  the  square 
brackets.  ■ 

Example  3.2  Consider  the  following  expression,  loop,  of  Fun: 

(let  g  =  (fun  f  x  =>  (f1  (fn  y  =>  y2)3)4)5 
in  (g6  (fn  z  =>  z7)8)9)10 

It  defines  a  function  g  that  is  applied  to  the  identity  function  fn  z  =>  z7. 
The  function  g  is  defined  recursively:  f  is  its  local  name  and  x  is  the  formal 
parameter.  Hence  the  function  will  ignore  its  actual  parameter  and  call  itself 
recursively  with  the  argument  fn  y  =>  y2.  This  will  happen  again  and  again 
so  the  program  loops.  ■ 

3.1.1  The  Analysis 

Abstract  domains.  We  shall  now  show  how  to  specify  O-CFA  analyses. 
These  may  be  regarded  as  the  simplest  possible  form  of  Control  Flow  Analysis 
in  that  no  context  information  is  taken  into  account.  As  will  become  clear 
in  Section  3.6,  this  is  what  the  number  0  is  indicating. 

The  result  of  a  O-CFA  analysis  is  a  pair  (C,  p)  where: 
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•  C  is  the  abstract  cache  associating  abstract  values  with  each  labelled 
program  point. 

•  p  is  the  abstract  environment  associating  abstract  values  with  each 
variable. 

This  is  made  precise  by: 

v  €  Val  =  'P(Term)  abstract  values 

p  €  Env  =  Var  — >  Val  abstract  environments 

C  €  Cache  =  Lab  — ►  Val  abstract  caches 

Here  an  abstract  value  v  is  an  abstraction  of  a  set  of  functions:  it  is  a  set  of 
terms  of  the  form  fn  x  =>  eo  or  fun  /  x  =>  eo.  We  will  not  be  recording  any 
constants  in  the  abstract  values  because  the  analysis  we  shall  specify  is  a  pure 
Control  Flow  Analysis  with  no  Data  Flow  Analysis  component;  in  Section 
3.5  we  shall  show  how  to  extend  it  with  Data  Flow  Analysis  components. 
Furthermore,  we  do  not  need  to  assume  that  all  bound  variables  are  distinct 
and  that  all  labels  are  distinct,  but  clearly,  greater  precision  is  achieved  if 
this  is  the  case.  As  we  shall  see  an  abstract  environment  is  an  abstraction  of 
a  set  of  environments  occurring  in  closures  at  run-time  (see  the  semantics  in 
Subsection  3.2.1).  In  a  similar  way  an  abstract  cache  might  be  considered  as 
an  abstraction  of  a  set  of  execution  profiles:  as  discussed  below  some  texts 
prefer  to  combine  the  abstract  environment  with  the  abstract  cache. 


Example  3.3  Consider  the  expression  ((fn  x  =>  x1)2  (fn  y  =>  y3)4)5 
of  Example  3.1.  The  following  table  contains  three  guesses  of  a  0-CFA  anal¬ 
ysis: 


(Ce,Pe) 

(Q,£) 

1 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

{fn  x  =>  x*,fn  y  =>  y3} 

2 

(fn  x  =>  x1} 

{fn  x  =>  x1} 

{fn  x  =>  x\fn  y  =>  y3} 

3 

0 

0 

{fn  x  =>  x\fn  y  =>  y3} 

4 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

{fn  x  =>  x* , f n  y  =>  y3} 

5 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

{fn  x  =>  x1, fn  y  =>  y3} 

X 

{fn  y  =>  y3} 

0 

{fn  x  =>  x1, fn  y  =>  y3} 

y 

0 

0 

{fn  x  =>  x\fn  y  =>  y3} 

Intuitively,  the  guess  (Ce,p<.)  of  the  first  column  is  acceptable  whereas  the 
guess  (C ',/?{)  of  the  second  column  is  wrong:  it  would  seem  that  fn  x  => 
x1  is  never  called  since  p{(x)  =  0  indicates  that  x  will  never  be  bound  to 
any  closures.  Also  the  guess  (C {',/%')  of  the  third  column  would  seem  to  be 
acceptable  although  clearly  more  imprecise  than  (Ce,pe)-  ■ 
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Example  3.4  Let  us  consider  tne  expression,  loop,  of  Example  3.2  and 
introduce  the  following  abbreviations  for  abstract  values: 


f  =  fun  f  x  =>  (f1  (fn  y  =>  y2)3)4 
\6y  =  fn  y  =>  y2 
idz  =  fn  z  =>  z7 


of  a  O-CFA  analysis  for  this  program  is 


One  guess 

Cip(l)  =  {f} 

C,p(2)  =  0 

Cip(3)  =  {idy} 

Clp(4)  =  0 

C|P(5)  =  {f} 


C.p(6) 

=  {0 

CiP(7) 

=  0 

Cip(8) 

=  R} 

C,P(9) 

=  0 

Cip(10) 

=  0 

(Cip,Pip) 

defined  by: 

Mf) 

=  {f} 

Ms) 

=  (0 

Mx) 

—  {idy,  id^} 

pip(y) 

=  0 

Pip(z) 

=  0 

Intuitively,  this  is  an  acceptable  guess.  The  choice  of  pjp  (g)  =  {f}  reflects  that 
g  will  evaluate  to  a  closure  constructed  from  that  abstraction.  The  choice  of 
pip(x)  =  {idy,  id* }  reflects  that  x  will  be  bound  to  closures  constructed  from 
both  abstractions  in  the  course  of  the  evaluation.  The  choice  of  Qp(10)  =  0 
reflects  that  the  evaluation  of  the  expression  will  never  terminate.  ■ 


We  have  already  said  that  Control  Flow  Analysis  computes  the  interproce¬ 
dural  flow  information  used  in  Section  2.5.  It  is  also  instructive  to  point 
out  the  similarity  between  Control  Flow  Analysis  and  Definition-Use  chains 
(du-chains)  for  imperative  languages  (see  Subsection  2.1.5):  in  both  cases  we 
attempt  to  trace  how  definition  points  reach  points  of  use.  In  the  case  of 
Control  Flow  Analysis  the  definition  points  are  the  points  where  the  function 
abstractions  are  created,  and  the  use  points  are  the  points  where  functions 
are  applied;  in  the  case  of  Definition-Use  chains  the  definition  points  are  the 
points  where  variables  are  assigned  a  value,  and  the  use  points  are  the  points 
where  values  of  variables  are  accessed. 

Remark.  Clearly  an  abstract  cache  C  :  Lab  Val  and  an  abstract  environ¬ 
ment  p  :  Var  -»  Val  can  be  combined  into  an  entity  of  type  ( Var  U  Lab)  -> 
Val.  Some  texts  dispense  with  the  labels  altogether,  simply  using  an  abstract 
environment  and  no  abstract  cache,  by  ensuring  that  all  subterms  are  prop¬ 
erly  “labelled”  by  variables.  This  type  of  expression  frequently  occurs  in  the 
internals  of  compilers  in  the  form  of  “continuation  passing  style” ,  “A-normal 
form”  or  “three  address  code” .  We  have  abstained  from  doing  so  in  order  to 
illustrate  that  the  techniques  not  only  work  for  compiler  intermediate  forms 
but  also  for  general  programming  languages  and  calculi  for  computation;  this 
flexibility  is  useful  when  dealing  with  non-standard  applications  (as  discussed 
in  the  Concluding  Remarks).  ■ 
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[con]  (C,  p)  (=  cl  always 

[war]  (C,p)  |=  xl  iff  p{x)  C  C(^) 

[fn]  (C,p)  [=  (fn  x  =>  eo)e  iff  {fn  x  =>  eo}  C  C(£) 

[fun]  (C,p)  |=  (fun  /  x  =>  eo)*  iff  {fun  f  x  =>  eo}  C  C(£) 

[app]  (C ,p)  (t{1  42)1 

iff  (C,p)|=fJl  A  (C  ,p)|=#  A 
(V(fn  z  =>  €  C(/i)  : 

(C,p)Nio°  A 

C(/2)  C  p(x)^  A  C(4)  c  C(0)  A 

(V(fun  f  x  =>  tg0)  e  C(£i)  : 

(C>  p)  f0°  A 

C(/2)  C  p(z)  A  C(4)  C-  C(£)  A 
{fun  /  a:  =>  fo0}  C  p(/)) 

[i/]  (C,p)  [=  (if  #  then  f*1  else  f^2)* 

iff  (C,  p)  )=  fo°  A 

(C,p)h^  A  (C.flMa’A 
C(*i)  C  C(0  A  C(4)  C  C(/) 

[/ef]  (C,p)  (=  (let  a:  =  f{J;in  te22)e 

iff  (C,p)  |=  A  (C,p)h^2  A 
C(/i)  C  p(z)  A  C(/2)  C  C(£) 

[op]  (C,p)  f=  (f*1  op  #)*  iff  (C,p)  1=  t['  A  (C,p)  |=  # 

Table  3.1:  Abstract  Control  Flow  Analysis. 

Acceptability  relation.  It  remains  to  determine  whether  or  not  a 
proposed  guess  (C,p)  of  an  analysis  results  is  in  fact  an  acceptable  0-CFA 
analysis  for  the  program  considered.  We  shall  give  an  abstract  specification 
of  what  this  means;  having  studied  its  theoretical  properties  (in  Section  3.2) 
we  then  consider  how  to  compute  the  desired  analysis  (in  Sections  3.3  and 
3.4). 

It  is  instructive  to  point  out  that  the  abstract  specification  corresponds  to  an 
implicit  formulation  of  the  data  flow  equations  of  Chapter  2;  it  will  be  used 
to  determine  whether  or  not  a  a  guess  is  indeed  an  acceptable  solution  to 
the  analysis  problem.  The  syntax  directed  and  constraint  based  formulations 
(of  Sections  3.3  and  3.4)  correspond  to  explicit  formulations  of  the  data  flow 
equations  from  which  an  iterative  algorithm  in  the  spirit  of  Chaotic  Iteration 


3.1  Abstract  O-CFA  Analysis 


145 


(Section  1.7)  can  be  used  to  compute  an  analysis  result. 

For  the  formulation  of  the  abstract  O-CFA  analysis  we  shall  write 

(C,p)\=e 

for  when  (C ,p)  is  an  acceptable  Control  Flow  Analysis  of  the  expression  e. 
Thus  the  relation  “|=”  has  functionality: 

j=  :  (Cache  x  Env  x  Exp)  — >  {true,  false} 

and  its  defining  clauses  are  given  in  Table  3.1  (writing  “always”  for  “iff  true”); 
they  are  explained  below. 

The  clause  [con]  places  no  demands  on  C(f)  because  we  axe  not  tracking 
any  data  values  in  the  pure  O-CFA  analysis  considered  here  and  because  we 
assume  that  there  are  no  functions  among  the  constants;  the  clause  can  be 
reformulated  as 

(C,p)  (=  cl  iff  0  C  Q(t) 
thereby  highlighting  this  point. 

The  clause  [war]  is  responsible  for  linking  the  abstract  environment  into  the 
abstract  cache:  so  in  order  for  (C,  p)  to  be  an  acceptable  analysis,  everything 
the  variable  x  can  evaluate  to  has  to  be  included  in  what  may  be  observed 
at  the  program  point  t\  p(x)  C  C(l). 

The  clauses  [/h]  and  [fun]  simply  demand  that  in  order  for  (C,  p)  to  be  an 
acceptable  analysis,  the  functional  term  (fn  x  =>  eo  or  fun  f  x  ->  e0)  must 
be  included  in  C(f);  this  says  that  the  term  is  part  of  a  closure  that  can  arise 
at  program  point  l  during  evaluation.  Note  that  these  clauses  do  not  demand 
that  (C,  p)  is  an  acceptable  analysis  result  for  the  bodies  of  the  functions;  the 
clause  for  function  application  will  take  care  of  that. 

Before  turning  to  the  more  complicated  clause  [app]  let  us  consider  the  clauses 
[t/j  and  [let].  They  contain  “recursive  calls”  demanding  that  subexpressions 
must  be  analysed  in  consistent  ways  using  (C,p);  additionally,  the  clauses 
explicitly  link  the  values  produced  by  subexpressions  to  the  value  of  the 
overall  expression,  and  in  the  case  of  [Zef]  also  the  abstract  cache  is  linked 
into  the  abstract  environment.  The  interplay  between  the  clauses  [t/ar]  and 
[let]  is  illustrated  in  Figure  3.1;  as  in  Chapter  2  an  arrow  indicates  a  flow  of 
information.  The  clause  [op]  follows  the  same  overall  pattern. 

Clause  [app]  also  contains  “recursive  calls”  demanding  that  the  operator  t[l 
and  the  operand  t^2  can  be  analysed  using  (C,p).  For  each  term  fn  x  =>  tg° 
that  may  reach  the  operator  position  ( l\ ),  i.e.  where 

(fn  x  =>  £q°)  £  C(fi) 


ii 
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Figure  3.1:  Pictorial  illustration  of  the  clauses  [let]  and  [uarj. 


it  further  demands  that  the  actual  parameter  (labelled  £2)  is  linked  to  the 
formal  parameter  (x) 

C(/a)  Q  pi?) 

and  that  the  result  of  the  function  evaluation  (labelled  £ 0 )  is  linked  to  the 
result  of  the  application  itself  (labelled  £) 

C(£0)  C  C(£) 

and  finally,  that  the  function  body  itself  can  be  analysed  using  (C,  p): 

(C  ,p)t=t‘0° 

This  is  illustrated  in  Figure  3.2.  For  terms  fun  /  x  =>  tg°  the  demands  are 
much  the  same  except  that  the  term  itself  additionally  needs  to  be  included 
in  p(f)  in  order  to  reflect  the  recursive  nature  of  fun  /  x  =>  tl0°. 

Example  3.5  Consider  Example  3.3  and  the  guesses  of  a  0-CFA  analysis 
for  the  expression.  First  we  show  that  (Ce,pe)  is  an  acceptable  guess: 

(Ce,pe)  N  ((fn  x  =>  x1)2  (fn  y  =>  y3)4)5 

Using  clause  [app]  and  Ce(2)  =  {fn  x  =>  x1}  we  must  check: 

(Ce,pe)  \=  (fn  X  =>  x1)2 
(Ce.Pe)  |=  (fn  y  =>  y3)4 


11 
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Figure  3.2:  Pictorial  illustration  of  the  clauses  [app],  \fn]  and  [varj. 


(C e,pe)  f=  xl 

Ce(4)  C  pe(x) 

Ce(l)  C.Ce(5) 

All  of  these  are  easily  checked  using  the  clauses  \fn]  and  [uar]. 

Next  we  show  that  (C' ,  p'e)  is  not  an  acceptable  guess: 

(CU)  £  ((fn  x  =>  x1)2  (fn  y  =>  y3)4)5 
We  do  so  by  proceeding  as  above  and  observing  that  C' (4)  £  p\{x).  m 

Note  that  the  clauses  contain  a  number  of  inclusions  of  the  form 

Ihs  C  rhs 

where  rhs  is  of  the  form  C(£)  or  p(x)  and  where  Ihs  is  of  the  form  C(£),  p(x),  or 
{t}.  These  inclusions  express  how  the  higher-order  entities  may  flow  through 
the  expression. 

It  is  important  to  observe  that  the  clauses  [fn]  and  [fun]  do  not  contain 
“recursive  calls”  demanding  that  subexpressions  must  be  analysed.  Instead 
one  relies  on  the  clause  [app]  demanding  this  for  all  “subexpressions”  that 
may  eventually  be  applied.  This  is  a  phenomenon  common  in  program  anal¬ 
ysis,  where  one  does  not  want  to  analyse  unreachable  program  fragments: 


148 


CONTROL  FLOW  ANALYSIS 


occasionally  results  obtained  from  these  parts  of  the  program  can  suppress 
transformations  in  the  reachable  part  of  the  program.  It  also  allows  us  to 
deal  with  open  systems  where  functions  may  be  supplied  by  the  environment; 
this  is  particularly  important  for  languages  involving  concurrency.  However, 
note  that  this  perspective  is  different  from  that  of  type  inference,  where  even 
unreachable  fragments  must  be  correctly  typed. 

In  the  terminology  of  Section  2.5  the  analysis  is  flow-insensitive  because  Fun 
contains  no  side  effects  and  because  we  analyse  the  operand  to  a  function  call 
even  when  the  operator  cannot  evaluate  to  any  function;  see  Exercise  3.3  for 
how  to  improve  on  this.  Also  the  analysis  is  context-insensitive  because  it 
treats  all  function  calls  in  the  same  way;  we  refer  to  Section  3.6  for  how  to 
improve  on  this. 

3.1.2  Well-definedness  of  the  Analysis 

Finally,  we  need  to  clarify  that  the  clauses  of  Table  3.1  do  indeed  define  a 
relation.  The  difficulty  here  is  that  the  clause  [ app ]  is  not  in  a  form  that 
allows  us  to  define  (C,  p)  (=  e  by  structural  induction  in  the  expression  e  - 
it  requires  checking  the  acceptability  of  (C  ,p)  for  an  expression  <q°  that  is 
not  a  subexpression  of  the  application  (t*1  tl£)1.  This  leads  to  defining  the 
relation  “f=”  of  Table  3.1  by  coinduction ,  that  is  as  the  greatest  fixed  point  of 
a  certain  functional.  An  alternative  will  be  to  define  the  analysis  as  the  least 
fixed  point  of  the  functional  but, /as  we  shall  see  in  Example  3.6  and  more 
formally  in  Proposition  3.16,  this  may  lead  to  problems. 

The  functional  Q.  Following  the  approach  of  Appendix  B  we  shall 
view  Table  3.1  as  defining  a  function: 

Q  :  ((Cache  x  Env  x  Exp)  — >  {true, false}) 

— >  ((Cache  x  Env  x  Exp)  ->  {true,  false}) 

As  an  example  we  have: 

Q(<2)(C,p,(let  x  =  t[] 1  in  te2*)() 

=  Q(C,p,t[l)  A  Q(C,p,#)  A  CfrJCff*)  A  C(/2)  C  C(f) 

Now  by  inspecting  Table  3.1  it  is  easy  to  verify  that  the  function  Q  con¬ 
structed  this  way  is  a  monotone  function  on  the  complete  lattice 

((Cache  x  Env  x  Exp)  — >  {true,  false},  C) 

where  the  ordering  C  is  defined  by: 

Qi  CQ2  iff  V(C ,p,e)  :  (<2i(C,p,e)  =  true)  =>  (Q2(C,p,e)  =  true ) 

Hence  Q  has  fixed  points  and  we  shall  define  “f=”  coinductively: 
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(=  is  the  greatest  fixed  point  of  Q 

The  following  example  motivates  the  use  of  a  coinductive  (i.e.  greatest  fixed 
point)  definition  as  opposed  to  an  inductive  (i.e.  least  fixed  point)  definition. 

Example  3.6  Consider  the  expression  loop  of  Example  3.4 

(let  g  =  (fun  f  x  =>  (f1  (fn  y  =>  y2)3)4)5 
in  (g6  (fn  z  =>  z7)8)9)10 


and  the  suggested  analysis  result  (Cip,pjp).  To  show  (C|p,pjp)  |=  loop  it  is, 
according  to  the  clause  [/et],  sufficient  to  verify  that 

(CiP,pip)  h  (fun  f  x  =>  (f1  (fn  y  =>  y2)3)4)5 
(C.P1?,P)  (=  (g6  (fn  z  =>  z7)8)9 

because  C|P(5)  C  pjp(g)  and  C|p(9)  C  Cip(10).  The  first  clause  follows  from 
\fwn]  and  for  the  second  clause  we  use  that  C|p(6)  =  {f}  so  it  is,  according  to 
[app],  sufficient  to  verify  that 

(Clp,plp)hg® 

(CiP,piP)  \=  (fn  z  =>  z7)8 
(Qp.pip)  (=  (f1  (fn  y  =>  y2)3)4 

because  C|P(8)  C  pip(x),  Cip(4)  C  C|P(9)  and  f  €  pjp(f).  The  first  two  clauses 
now  follow  from  [war]  and  [fn].  For  the  third  clause  we  proceed  as  above  and 
since  C|P(1)  =  {f}  it  is  sufficient  to  verify 

(QP,/3|P)  [=  f1 

(C|P,  pip)  \=  (fn  y  =>  y2)3 

(Clp,plp)  |=  (f1  (fn  y  =>  y2)3)4 

because  C|P(3)  C  pip(x),  Qp(4)  C  Cip(4)  srnd  f  €  pip(f ). 

Again  the  first  two  clauses  axe  straightforward  using  [war]  and  \fn]  but  in  the 
last  clause  where  we  have  encountered  a  circularity,  to  verify  (Qp,pip)  [=  (f1 
(fn  y  =>  y2)3)4  we  have  to  verify  (C|p,pip)  \=  (f1  (fn  y  =>  y2)3)4! 

To  solve  this  we  use  coinduction:  basically  this  amounts  to  assuming  that 
(Cip,  pip)  |=  (f1  (fn  y  =>  y2)3)4  holds  at  the  “inner  level”  and  proving  that 
it  also  holds  at  the  “outer  level” .  This  will  give  us  the  required  proof.  ■ 
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3.2  Theoretical  Properties 

In  this  section  we  shall  investigate  some  more  theoretical  properties  of  the 
Control  Flow  Analysis,  namely: 

•  semantic  correctness,  and 

•  the  existence  of  least  solutions. 

The  semantic  correctness  result  is  important  since  it  ensures  that  the  infor¬ 
mation  from  the  analysis  is  indeed  a  safe  description  of  what  will  happen 
during  the  evaluation  of  the  program.  The  result  about  the  existence  of  least 
solutions  ensures  that  all  programs  can  be  analysed  and  furthermore  that 
there  is  a  “best”  or  “most  precise”  analysis  result. 

As  in  Section  2.2,  the  material  of  this  section  may  be  skimmed  through  on  a 
first  reading;  however,  it  is  frequently  when  conducting  the  correctness  proof 
that  the  final  and  subtle  errors  in  the  analysis  are  found  and  corrected! 

3.2.1  Structural  Operational  Semantics 

Configurations.  We  shall  equip  the  language  Fun  with  a  Structural 
Operational  Semantics.  We  shall  choose  an  approach  based  on  explicit  envi¬ 
ronments  rather  than  substitutions  because  (as  discussed  in  the  Concluding 
Remarks)  a  substitution  based  semantics  does  not  preserve  the  identity  of 
functions  (and  hence  abstract  values)  during  evaluation.  So  a  function  defini¬ 
tion  will  evaluate  to  a  closure  containing  the  syntax  of  the  function  definition 
together  with  an  environment  mapping  its  tree  variables  to  their  values.  For 
this  we  introduce  the  following  categories 

v  €  Val  values 
p  6  Env  environments 


defined  by: 


v  ::=  c  |  close  t  in  p 

p  ::=  [  ]  |  p{ x  ^  u] 

A  function  abstraction  fn  x  =>  eo  will  then  evaluate  to  a  closure,  written 
close  (f n  x  =>  eo)  in  p;  similarly,  the  abstraction  fun  /  x  =>  eo  will  evaluate 
to  close  (fun  /  x  =>  eo)  in  p.  Our  definitions  do  not  demand  that  all  terms  t 
occurring  in  some  close  t  in  p  in  the  semantics  will  be  of  the  form  f  n  x  =>  eo 
or  fun  f  x  =>  eo;  however,  it  will  be  the  case  for  the  semantics  presented 
below. 

As  in  Section  2.5  we  shall  need  intermediate  configurations  to  handle  the 
binding  of  local  variables.  We  therefore  introduce  syntactic  categories  for 
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intermediate  expressions  and  intermediate  terms 

ie  €  IExp  intermediate  expressions 

it  €  ITerm  intermediate  terms 

that  extend  the  syntax  of  expressions  and  terms  as  follows: 

ie  ::=  it 1 

it  ::=  c  |  x  |  fn  x  =>  eo  |  fun  f  x->  e o  |  iei  ie2 

|  if  ie o  then  ei  else  e2  |  let  x  =  iei  in  e2  |  ie i  op  ie 2 
|  bind  p  in  ie  |  close  t  in  p 

The  role  of  the  bind-construct  is  much  as  in  Section  2.5:  bind  p  in  ie  records 
that  the  intermediate  expression  ie  has  to  be  evaluated  in  an  environment 
with  the  bindings  p.  (The  sequence  of  environments  of  nested  bind-constructs 
may  be  viewed  as  an  encoding  of  the  frames  of  a  run-time  stack.)  So  while 
close  t  in  p  is  a  fully  evaluated  value  this  is  not  the  case  for  bind  p  in  ie. 
We  shall  need  these  intermediate  terms  because  we  are  based  on  a  small  step 
semantics;  only  the  close-constructs  will  be  needed  for  a  big  step  variant  of 
the  semantics. 

Alternatively,  the  definitions  of  Val  and  Env  could  have  been  written  Val  = 
Const  4-  (Term  x  Env)  and  Env  =  Var  — *-fin  Val  (for  a  finite  mapping)  but 
it  is  important  to  stress  that  all  entities  are  defined  mutually  recursively  in 
the  manner  of  context-free  grammars.  Formally,  we  defined  an  environment  p 
as  a  list  but  nevertheless  we  shall  feel  free  to  regard  it  as  a  finite  mapping:  we 
write  dom(p)  for  {x  \  p  contains  [iH"  •]};  we  write  p{ x)  =  v  if  x  S  dom(p) 
and  the  rightmost  occurrence  of  [z  ■  •]  in  p  is  [2  1-4  i>],  and  we  write  p\X 
for  the  environment  obtained  from  p  by  removing  all  occurrences  of  [1  h>  •  ■  •] 
with  x  X.  For  the  sake  of  readability  we  shall  write  [a:  v]  for  [  j[x  ?;]. 

We  have  been  very  deliberate  in  when  to  use  intermediate  expressions  and 
when  to  use  expressions  although  it  is  evident  that  all  expressions  axe  also 
intermediate  expressions.  Since  we  do  not  evaluate  the  body  of  a  function 
before  it  is  applied  we  continue  to  let  the  body  be  an  expression  rather 
than  an  intermediate  expression.  Similar  remarks  apply  to  the  branches  of 
the  conditional  and  the  body  of  the  local  definitions.  Note  that  although 
an  environment  only  records  the  terms  fn  x  =>  eo  and  fun  /  x  =>  eo  in  the 
closures  bound  into  it,  we  do  not  lose  the  identity  of  the  function  abstractions 
as  eo  will  be  of  the  form  tl0°  and  hence  £0  may  be  used  as  the  “unique” 
identification  of  the  function  abstraction. 

Transitions.  We  are  now  ready  to  define  the  transition  rules  of  the  Struc¬ 
tural  Operational  Semantics  by  means  of  judgements  of  the  form 

p  b  ie\  ->  ie 2 


* 
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[t/ar] 

\M 

[fun] 

[«PPi] 
[a PP2] 


p  I-  xl  -4  vl  if  x  €  dom(p)  and  v  =  p(x) 

p  h  (fn  x  =>  eo )e  -4  (close  (fn  x  =>  eo)  in  po)* 
where  po  =  p  |  FV(fn  x  =>  eo) 

p  t-  (fun  /  x  =>  eo)*  -4  (close  (fun  /  x  =>  eo)  in  p0)* 
where  po  =  p  |  FV(fun  f  x  ->  e 0) 

p  h  iei  -4  ie'x 
p  h  (iei  ie2)*  -4  ( ie[  ie 2)* 

p  h  ie2  -4  iej 
p  h  (uf1  ie2y  -4  (uf1  ie^)< 


[appyn]  p  h  ((close  (fn  x  =>  ei)  in  pi)*1  Uj2)*  -4 

(bind  pi[x  i-4  u2]  in  ei)* 


[appfun]  p  h  ((close  (fun  /  x  =>  ex)  in  pi)*1  U22)*  -4 

(bind  p2[x  >4  v2]  in  ei)* 
where  p2  =  pj/  1-4  close  (fun  f  x  =>  e  1)  in  pi] 


[6tndi] 

[6tnd2] 


Pi  h  iei  -4  ie'x 

p  h  (bind  pi  in  iei)*  -4  (bind  pi  in  ze'j)* 
p  h  (bind  pi  in  uj1  )e  *4  uf 


Table  3.2:  The  Structural  Operational  Semantics  of  Fun  (part  1). 


given  by  the  axioms  and  inference  rules  of  Tables  3.2  and  3.3;  they  are  ex¬ 
plained  below.  The  idea  is  that  one  step  of  computation  of  the  expression 
iei  in  the  environment  p  will  transform  it  into  ie2. 

The  value  of  a  variable  is  obtained  from  the  environment  as  expressed  by  the 
axiom  [war].  The  axioms  [fn]  and  [fun]  construct  the  appropriate  closures; 
they  restrict  the  environment  p  to  the  free  variables  of  the  abstraction.  Note 
that  in  [fun ]  it  is  only  recorded  that  we  have  a  recursively  defined  function; 
the  unfolding  of  the  recursion  will  not  happen  until  it  is  called. 

The  clauses  for  application  shows  that  the  semantics  is  a  call-by-value  seman¬ 
tics:  In  an  application  we  first  evaluate  the  operator  in  a  number  of  steps 
using  the  rule  [app\]  and  then  we  evaluate  the  operand  in  a  number  of  steps 
using  the  rule  [appf]-  The  next  stage  is  to  use  one  of  the  rules  [app/n]  or 
[appfun]  to  bind  the  actual  parameter  to  the  formal  parameter  and,  in  the 
case  of  [app/un],  to  unfold  the  recursive  function  so  that  subsequent  recursive 
calls  will  be  bound  correctly.  We  shall  use  a  bind-construct  to  contain  the 
body  of  the  function  together  with  the  appropriate  environment.  Finally,  we 
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[«/il 

[*/z] 

[*/s] 

[/eti] 

[/et2] 


_ p  I-  t'ep  -4  iep _ 

p  I-  (if  ie o  then  ej  else  e2)*  -4  (if  iej)  then  ej  else  62)* 

p  h  (if  true*0  then  t*1  else  *4  t[ 

p  h  (if  false*0  then  ff1  else  tffY  -4  tl2 

_ p  I-  ie\  -4  ie[ _ 

p  h  (let  x  =  iei  in  e2)*  -4  (let  a:  =  ie[  in  e2)* 

p  h  (let  x  =  u*1  in  e-x)1  -4  (bind  [r  1-4  v ]  in  62)* 


[0P1] 

[oft] 

[oft] 


p  h  ie  1  -4  ie'j 

p  H  (iei  op  ie 2)*  -4  (ie'j  op  162)* 
p  h  ie2  -4 

p  h  (uf1  op  ie2)*  -4  (uj1  op  te!j)* 
p  I-  (uf1  op  v^Y  -4  u*  if  v  =  Vi  op  v2 


Table  3.3:  The  Structural  Operational  Semantics  of  Fun  (part  2). 


evaluate  the  bind-construct  using  rule  [bindi]  a  number  of  times,  and  we  get 
the  result  of  the  application  by  using  rule  [ftjrufc].  The  interplay  between 
these  rules  is  illustrated  by  the  following  example. 

Example  3.7  Consider  the  expression  ((fn  x  =>  x1)2  (fn  y  =>  y3)4)5  of 
Example  3.1.  It  has  the  following  derivation  sequence  (explained  below): 

[]  b  ((fn  x  =>  x1)2  (fn  y  =>  y3)4)5 
->  ((close  (fn  x  =>  x1)  in  [  ])2  (fn  y  =>  y3)4)5 

((close  (fn  x  =>  x1)  in  [  ])2  (close  (fn  y  =>  y3)  in  [  ])4)5 
(bind  [x  i-4  (close  (fn  y  =>  y3)  in  [  ])]  in  x1)5 
(bind  [x  i-4  (close  (fn  y  =>  y3)  in  [  ])]  in 
(close  (fn  y  =>  y3)  in  [  j)1)5 
-4  (close  (fn  y  =>  y3)  in  [  ])5 

First  [appi]  and  [fn]  are  used  to  evaluate  the  operator,  then  [app2]  and  [fn] 
are  used  to  evaluate  the  operand  and  [app/n]  introduces  the  bind-construct 
containing  the  local  environment  [x  1-4  (close  (fn  y  =>  y3)  in  [  ])]  needed 
to  evaluate  its  body.  So  x1  is  evaluated  using  [6indi]  and  [war] ,  and  finally 
[bind2]  is  used  to  get  rid  of  the  local  environment.  ■ 

The  semantics  of  the  conditional  is  the  usual  one:  first  the  condition  is  eval- 
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uated  in  a  number  of  steps  using  rule  [i/i]  and  then  the  appropriate  branch 
is  selected  by  rules  [if2]  and  [i/3].  For  the  local  definitions  we  first  compute 
the  value  of  the  bound  variable  in  a  number  of  steps  using  rule  [/eti]  and 
then  we  introduce  a  bind-construct  using  rule  [lek]  reflecting  that  the  body 
of  the  let-construct  has  to  be  evaluated  in  an  extended  environment.  The 
rules  [bindi]  and  [binda]  are  now  used  to  compute  the  result.  For  binary  ex¬ 
pressions  we  first  evaluate  the  arguments  using  [opx]  and  [op2]  and  then  the 
operation  itself,  denoted  op,  is  performed  using  [op3]. 

As  in  Chapter  2  the  labels  have  no  impact  on  the  semantics  but  are  merely 
carried  along.  It  is  important  to  note  that  the  outermost  label  never  changes 
while  inner  labels  may  disappear;  see  for  example  the  rules  [1/2]  and  [bindi]. 
This  is  an  important  property  of  the  semantics  that  is  exploited  by  the  0-CFA 
analysis. 

Example  3.8  Let  us  consider  the  expression,  loop 

(let  g  =  (fun  f  x  =>  (f1  (fn  y  =>  y2)3)4)5 
in  (g6  (fn  2  =>  z7)8)9)10 

of  Example  3.2  and  see  how  the  informal  explanation  of  its  semantics  is 
captured  in  the  formal  semantics.  First  we  introduce  abbreviations  for  three 
closures: 

f  =  close  (fun  f  X  =>  (f1  (fn  y  =>  y2)3)4)  in  [] 

idy  =  close  (fn  y  =>  y2)  in  [  ] 

id*  =  close  (fn  2  =>  z7)  in  [  ] 

Then  we  have  the  following  derivation  sequence 

[  ]  h  loop 

-»  (let  g  =  f5  in  (g6  (fn  z  =>  z7)8)9)10 
-4  (bind  [g  t->  f]  in  (g6  (fn  z  =>  z7)8)9)10 

— i  (bind  [g  h>  f]  in  (f6  (fn  z  =>  z7)8)9)10 

(bind  [g  f]  in  (f6  id8)9)10 
-4  (bind  [g  1-4  f]  in 

(bind  [f  1 — ^  f][x  id*]  in  (f 1  (fn  y  =>  y2)3)4)9)10 
-4*  (bind  [g  1-4  f]  in 

(bind  [f  4  f][x  4  id*]  in 

(bind  [f  h*  f][x  ^  idy]  in  (f 1  (fn  y  =>  y2)3)4)4)9)10 

-4* 


showing  that  the  program  does  indeed  loop. 


3.2  Theoretical  Properties 


155 


[bind]  (C,p)  (=  (bind  p  in  Uq0)1 

iff  (C  ,p)  f=  itfc  A  C(4)  c  C(f)  A  p  Tip 

[close]  (C,p)  (=  (close  to  in  p)1 

iff  {t0}  C  C(£)  A  p  Tip 


Table  3.4:  Abstract  Control  Flow  Analysis  for  intermediate  expressions. 

3.2.2  Semantic  Correctness 

We  shall  formulate  semantic  correctness  of  the  Control  Flow  Analysis  as  a 
subject  reduction  result,  this  is  an  approach  borrowed  from  type  theory  and 
merely  says  that  an  acceptable  result  of  the  analysis  remains  acceptable  under 
evaluation.  However,  in  order  to  do  that  we  need  to  extend  the  analysis  to 
intermediate  expressions. 

Analysis  of  intermediate  expressions.  The  clauses  for  the  con¬ 
structs  bind  p  in  ie  and  close  to  in  p  are  given  in  Table  3.4;  the  remaining 
clauses  are  as  in  Table  3.1  (with  the  obvious  replacements  of  expressions  with 
intermediate  expressions). 

The  clause  [bind]  reflects  that  its  body  will  be  executed  and  hence  whatever 
it  evaluates  to  will  also  be  a  possible  value  for  the  construct.  Additionally,  it 
expresses  that  there  is  a  certain  relationship  'll  between  the  local  environment 
(of  the  semantics)  and  the  abstract  environment  (of  the  analysis).  The  clause 
[close]  is  similar  in  spirit  to  the  clauses  for  function  abstraction:  the  term  of 
the  closure  is  a  possible  value  of  the  construct.  Additionally,  there  has  to  be 
a  relationship  T 1  between  the  two  environments. 

Correctness  relation.  The  purpose  of  the  global  abstract  environ¬ 
ment,  p,  is  to  model  all  of  the  local  environments  arising  during  evaluation. 
We  formalise  this  by  defining  the  correctness  relation 

'll :  (Env  x  Env)  — >  {true,  false} 

and  demanding  that  p  Tl  p  for  all  local  environments,  p,  occurring  in  the 
intermediate  expressions.  We  then  define: 

p  Tl  p  iff  Vx  €  dom(p)  C  dom{p)  Vtx  Vpx  : 

(p(x)  =  close  tx  in  px)  =>■  ( tx  £  p(x)  A  px  Tl  p) 

This  clearly  demands  that  the  function  abstraction,  tx,  in  p(x)  must  be  an 
element  of  p(x).  It  also  shows  that  all  local  environments  reachable  from  p, 
e.g.  px,  must  be  modelled  by  p  as  well.  Note  that  the  relation  Tl  is  well- 
defined  because  each  recursive  call  is  performed  on  a  local  environment  that 


156 


CONTROL  FLOW  ANALYSIS 


p  I-  ie 


n 


— >  ie  ->  ie 


P  (C,p)  (C,p)  (C,j5) 


t= 
(C,P) 


Figure  3.3:  Preservation  of  analysis  result. 

is  strictly  smaller  than  that  of  the  call  itself;  thus  a  simple  proof  by  well- 
founded  induction  (Appendix  B)  suffices  for  showing  the  well-definedness  of 
TZ. 

Example  3.9  Suppose  that: 

p  <=  [x  h*  close  £i  in  p\\[y  h*  close  £2  in  P2] 

Pi  =  U 

P2  =  [x  i-4  close  £3  in  p$] 

P3  =  [] 

Then  pTZp  amounts  to  {£i,£3}  G p{x)  A  {£2}  C  p(y).  ■ 

We  shall  sometimes  find  it  helpful  to  split  the  definition  of  TZ  into  two  com¬ 
ponents.  For  this  we  make  use  of  the  auxiliary  relation 

V  :  (Val  x  (Env  x  Val))  -»  {true,  false} 
and  define  V  and  TZ  by  mutual  recursion: 

v  V  ( p ,  v )  iff  V£  Vp  :  (v  =  close  £  in  p)  =$■  (£  £  v  A  p  TZ  p) 

pTZp  iff  Vx  G  dom{p)  C  dom(p)  :  p{x)  V  (p,  p(x)) 

Clearly  the  two  definitions  are  equivalent. 

Correctness  result.  The  correctness  result  is  now  expressed  by: 


Theorem  3.10 

If  p  TZ  p  and  p  h  ie  ->  ie'  then  ( C,p)  ie  implies  (C,p)  ie1. 


This  is  illustrated  in  Figure  3.3  for  a  terminating  evaluation  sequence  p  \~ 
ie  ->*  vl]  note  that  the  result  is  analogous  to  that  of  Corollary  2.17  for  the 
Live  Variables  Analysis  in  Chapter  2. 
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The  intuitive  content  of  the  result  is  as  follows: 

If  there  is  a  possible  evaluation  of  the  program  such  that  the 
function  at  a  call  point  evaluates  to  some  abstraction,  then  this 
abstraction  has  to  be  in  the  set  of  possible  abstractions  computed 
by  the  analysis. 

To  see  this  assume  that  p  b  tl  ->*  (close  to  in  PoY  and  that  (C ,p)  f=  tl  as 
well  as  p  TZ  p.  Then  Theorem  3.10  (and  an  immediate  numerical  induction) 
gives  that  ( C,p)  J=  (close  to  in  PoY-  Now  from  the  clause  [dose]  of  Table 
3.4  we  get  that  to  €  C(£)  as  was  claimed.  It  is  worth  noticing  that  if  the 
program  is  closed,  i.e.  if  it  does  not  contain  free  variables,  then  p  will  be  [  ] 
and  the  condition  p  77  p  is  trivially  fulfilled. 

Note  that  the  theorem  expresses  that  all  acceptable  analysis  results  remain 
acceptable  under  evaluation.  One  advantage  of  this  is  that  we  do  not  need  to 
rely  on  the  existence  of  a  least  or  “best”  solution  (to  be  proved  in  Subsection 
3.2.3)  in  order  to  formulate  the  result.  Indeed  the  result  does  not  say  that 
the  “best”  solution  remains  “best”  -  merely  that  it  remains  acceptable.  More 
importantly,  the  result  opens  up  the  possibility  that  the  efficient  realisation 
of  Sections  3.3  and  3.4  computes  a  more  approximate  solution  than  the  least 
(perhaps  using  the  techniques  of  Chapter  4).  Finally,  note  that  the  formula¬ 
tion  of  the  theorem  crucially  depends  on  having  defined  the  analysis  for  all 
intermediate  expressions  rather  than  just  all  ordinary  expressions. 

We  shall  now  turn  to  the  proof  of  Theorem  3.10.  We  first  state  an  important 
observation: 

Fact  3.11  If  (C ,p)  f=  it*'  and  C(/x)  C  C(/2)  then  (C ,p)  |=  it1*.  m 

Proof  By  cases  on  the  clauses  for  “f=” .  ■ 

We  then  prove  Theorem  3.10: 

Proof  We  assume  that  p  Tip  and  (C,  p)  (=  ie  and  prove  (C,  p)  f=  ie'  by  induction 
on  the  structure  of  the  inference  tree  for  p  t-  ie  — >  ie' .  Most  cases  simply  amount 
to  inspecting  the  defining  clause  for  (C,p)  j=  ie;  note  that  this  method  of  proof 
applies  to  all  fixed  points  of  a  recursive  definition  and  in  particular  also  to  the 
greatest  fixed  point.  We  only  give  the  proofs  for  some  of  the  more  interesting  cases. 

The  case  [war],  Here  p  I-  ie  — »  ie'  is: 

p  I-  xl  — y  vl  because  x  €  dom(p)  and  v  =  p(x) 

If  v  —  c  there  is  nothing  to  prove  so  suppose  that  v  =  close  to  in  po-  From  p  77  p 
we  get  v  V  (p,p(x))  and  hence  to  6  p(x)  and  po  7 Z  p.  From  (C,  p)  |=  ie  we  get 
p(x)  C  C(£),  and  hence  to  €  C(f).  Since  to  €  C(£)  and  po  77  p  we  have  established 
(C  ,p)He'. 
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The  case  [/n].  Here  p  I-  ie  — »•  ie'  is: 

p  I-  (fn  x  ->  eoY  -4  (close  (fn  x  =>  eo)  in  poY 
where  po  =  p  \  FV( fn  x  =>  eo) 

From  (C ,  p)  (=  ie  we  get  (fn  x  =>  eo)  €  C(f);  from  p  72  p  it  is  immediate  to  get 
po  72.  p;  this  then  establishes  (C,p)  j=  ie'. 

The  case  [oppj.  Here  p  I-  te  -4  ie'  is: 

p  I-  (tei  ie^Y  -4  (ie'i  ie-i)1  because  p  I—  *ei  — ►  ie'i 

The  defining  clauses  of  (C,  p)  f=  ie  and  (C,  p)  (=  ie'  are  equal  except  that  the  former 
has  (C,p)  (=  tei  where  the  latter  has  (C,p)  (=  ie[ .  From  the  induction  hypothesis 
applied  to 

(C,  p)  (=  ie i,  p  72  p ,  and  p  I-  iei  -4  ie'i 
we  get  (C,  p)  (=  ie'i  and  the  desired  result  then  follows. 

The  case  [appfn].  Here  p  t—  ie  — >■  ie'  is: 

p  h  ((close  (fn  x  =>  fg°)  in  Pi)*1  vi* Y  (bind  pi  [a:  1-4  t>2]  in  tl0°Y 

From  (C,p)  \=  ie  we  have  (C,p)  (close  (fn  x  =>  £g°)  in  PiY 1  which  yields: 

(fn  x  =>  tg0)  6  C(£i)  and  pi  72  p 

Further  we  have  (C,  p)  |=  ti*2;  in  the  case  where  v2  =  c,  it  is  immediate  that 

u2  V  (p,C(f2)) 

and  in  the  case  where  V2  =  close  i2  in  p2  it  follows  from  the  definition  of  (C,  p)  \= 
vl22 .  Finally,  the  first  universally  quantified  formula  of  the  definition  of  (C,p)  \=  ie 
gives: 

(C,p)  (=  <o°.  C(f2)  C  p(x),  and  C(4)  C  C(£) 

Now  observe  that  u2  V  (p,  p(x))  since  C(i2)  C  p(x)  follows  from  the  clause  ( app/„ )• 
Since  pi  72  p  we  now  have 

(C,p)t=tg°,  C(f0)  c  C(f),  and  (pi [x  1-4  u2])  72  p 

and  this  establishes  the  desired  (C,p)  |=  ie'. 

The  case  [&ind2].  Here  p  I-  ie  -4  ie'  is: 

p  h  (bind  pi  in  tql  )*  -4 

From  (C,p)  (=  ie  we  have  (C,p)  (=  uf1  as  well  as  C(£i)  C  C(f)  and  the  desired 
(C,  p)  |=  uf  follows  from  Fact  3.11. 

This  completes  the  proof.  ■ 
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Example  3.12  Prom  Example  3.7  we  have: 

[  ]  h  ((fn  x  =>  x1)2  (fn  y  =>  y3)4)5  ->*  (close  (fn  y  =>  y3)  in  [  ])5 

Next  let  (C t,pe)  be  as  in  Example  3.3.  Clearly  [  ]  7 Z  pe  and  from  Example 
3.5  we  have: 


(C„pe)|=((fn  x  =>  x1)2  (fn  y  =>  y3)4)5 
According  to  Theorem  3.10  we  can  now  conclude: 

(Ce,Pe)  f=  (close  (fn  y  =>  y3)  in  [  ])5 

Using  Table  3.4  it  is  easy  to  check  that  this  is  indeed  the  case.  ■ 

3.2.3  Existence  of  Solutions 

Having  defined  the  analysis  in  Table  3.1  it  is  natural  to  ask  the  following 
question:  Does  each  expression  e  admit  a  Control  Flow  Analysis,  i.e.  does 
there  exist  (C,  p)  such  that  (C,  p)  f=  e?  We  shall  show  that  the  answer  to  this 
question  is  yes. 

However,  this  does  not  exclude  the  possibility  of  having  many  different  analy¬ 
ses  for  the  same  expression  so  an  additional  question  is:  Does  each  expression 
e  have  a  “least”  Control  Flow  Analysis,  i.e.  does  there  exists  (Co,po)  such 
that  (C0,  p0)  \=  e  and  such  that  whenever  (C,p)  j=  e  then  (C0,po)  is  “less 
than”  (C,  p )?  Again,  the  answer  will  be  yes. 

Here  “least”  is  with  respect  to  the  partial  order  defined  by: 

(Ci ,pi)  C  (C2,p2)  iff  (W  G  Lab  :  Z^l)  C  C2(0)  A 
(Vx  G  Var  :  pi(x)  C  p2(x)) 

It  will  be  the  topic  of  Sections  3.3  and  3.4  (and  Mini  Project  3.1)  to  show  that 
the  least  solution  can  be  computed  efficiently  for  all  expressions.  However,  it 
may  be  instructive  to  give  a  general  proof  for  the  existence  of  least  solutions 
also  for  intermediate  expressions.  To  this  end  we  recall  the  notion  of  a  Moore 
family  (see  Appendix  A  and  Exercise  2.7): 

A  subset  Y  of  a  complete  lattice  L  =  (L,  C)  is  a  Moore  family  if 
and  only  if  (["]  Y')  G  Y  for  all  Y'  C  Y. 

This  property  is  also  called  the  model  intersection  property  because  whenever 
we  take  the  “intersection”  of  a  number  of  “models”  we  still  get  a  “model” . 
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Proposition  3.13 

For  all  ie  G  IExp  the  set  {(C,p)  j  (C,p)  \=  ie}  is  a  Moore  family. 


It  is  an  immediate  corollary  that  all  intermediate  expressions  ie  admit  a 
Control  Flow  Analysis:  Let  Y'  be  the  empty  set;  then  [~|  Y'  is  an  element  of 
{( C,p)  |  (C,p)  f=  ie}  showing  that  there  exists  at  least  one  analysis  of  ie. 

It  is  also  an  immediate  corollary  that  all  intermediate  expressions  have  a  least 
Control  Flow  Analysis:  Let  Y'  be  the  set  {(C,p)  |  (C,p)  (=  ie};  then  [~] Y'  is 
an  element  of  {(C,p)  |  (C,p)  (=  ie}  so  it  will  also  be  an  analysis  of  ie.  Clearly 
\~\Y'  C  (C,  p)  for  all  other  analyses  (C,  p)  of  ie  so  it  is  the  least  analysis  result. 

In  preparation  for  the  proof  of  Proposition  3.13  we  shall  first  establish  an 
auxiliary  result  for  72  and  V: 


Lemma  3.14 

(i)  For  all  p  G  Env  the  set  {p  |  p  72  p}  is  a  Moore  family. 

(ii)  For  all  v  G  Val  the  set  {(p,  v)  \v  V  (p,  v)}  is  a  Moore  family.  ■ 


Proof  To  prove  (i)  we  proceed  by  well-founded  induction  on  p  (which  is  also  the 
manner  in  which  the  existence  of  the  predicate  was  proved).  Now  assume  that 


Vi  G  I :  p  72  pi 

for  some  index  set  I  and  let  us  show'  that  p  72  (flip.)-  For  this  consider  x,  tx,  and 
Pi  such  that: 

p(z)  =  close  tx  in  p* 


We  then  know 

Vi  G  /  :  tx  €  pi(x)  A  p*  72  pi 
and  using  the  induction  hypothesis  it  follows  that 

€  (|  |iPi)(s)  A  px  72  (|  |ip>) 

(taking  care  when  7  =  0). 


To  prove  (ii)  we  simply  expand  the  definition  of  V  and  note  that  the  result  then 
follows  from  (i).  ■ 


We  now  prove  Proposition  3.13  using  coinduction  (see  Appendix  B): 

Proof  The  ternary  relation  |=  of  Tables  3.1  and  3.4  is  the  greatest  fixed  point  of 
a  function  Q  as  explained  in  Section  3.1.  Now  assume  that 

Vi  G  I :  (Ci,  pi)  f=  ie 

and  let  us  prove  that  pi)  }=  ie.  We  shall  proceed  by  coinduction  (see  Ap¬ 

pendix  B)  so  we  start  by  defining  the  ternary  relation  Q'  by: 

(C ',?)  Q'  ie'  iff  (C'.i?)  =(_li(C.-,pi)  A  Vi  G  /  :  (Ci,p<)  |=  ie' 
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It  is  then  immediate  that  we  have: 

n<fc.a>  Q' ie 

The  coinduction  proof  principle  requires  that  we  prove 

Q'  E  Q(Q') 

and  this  amounts  to  assuming  {€',(?)  Q'  ie'  and  proving  that  (C>p>)  (Q(Q'))  ie'. 
So  let  us  assume  that 

Vi  e  I :  (€,,%)  \=  ie1 

and  let  us  show  that: 

n«6.*>  (Qw')) ie> 

For  this  we  consider  each  of  the  clauses  for  ie'  in  turn. 

Here  we  shall  only  deal  with  the  more  complicated  choice  ie'  =  (iff1  iff2)*.  From 

Vie  I :  (Ci,pi)  (=  (iff1  iff2)* 
we  get  Vi  €  I :  (Ci,pi)  \=  iff1  and  hence: 

n<(Ci,pO  Q'  it fl 

Similarly  we  get:  _ 

rii(Ci,p.)  q'  a? 

Next  consider  (fn  x  =>  ff°)  €  {^((^(ii))  and  let  us  prove  that: 

r|‘(c<(<»))  E  n*(c*(^o))  c  f|<(c<(/)), 

For  all  i  e  I  we  have  that  (C;, p<)  (=  ie'  and  since  (fn  x  =>  ff°)  6  Ci(£i)  we  have 

Ci(^2)  C  pi(x),  Ci(fo)  C  C i(£),  and  (C ,-,p<)  |=  f£° 

and  this  then  gives  (3.1)  as  desired  (taking  care  when  I  =  0).  The  case  of 
(fun  /  x  =>  tg°)  6  n,(Ci(fi))  >s  similar.  This  completes  the  proof.  ■ 

Example  3.15  Let  us  return  to  Example  3.5  and  consider  the  following 
potential  analysis  results  for  ((fn  x  =>  x1)2  (fn  y  =>  y3)4)5: 


(Qi  Pe) 

(£">&') 

1 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

2 

{fn  x  =>  x1} 

{fn  x  =>  x1} 

{fn  x  =>  x1} 

3 

0 

{fn  x  =>  x1} 

{fn  y  =>  y3} 

4 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

5 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

X 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

{fn  y  =>  y3} 

y 

0 

{fn  x  =>  x1} 

{fn  y  =>  y3} 

ii 
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It  is  straightforward  to  verify  that 

(C;,&)M(fn  X  =>  X1)2  (fn  y  =>  y3)4)5 
(C",£')  N  ((fn  x  =>  x1)2  (fn  y  =>  y3)4)5 
Now  Proposition  3.13  ensures  that  also: 

(C£  n  C",  ^  n  {=  ((fn  x  =>  x1)2  (fn  y  =>  y3)4)5 

Neither  (C £,/%)  nor  (C",p^')  is  a  least  solution.  Their  “intersection”  (C(  n 
QiPe  n  Pe)  is  smaller  and  equals  (Ce,pe)  which  turns  out  to  be  the  least 
analysis  result  for  the  expression.  ■ 

3.2.4  Coinduction  versus  Induction 

One  of  the  important  aspects  of  the  development  of  the  abstract  Control 
Flow  Analysis  in  Table  3.1  is  the  coinductive  definition  of  the  acceptability 
relation: 


|=  as  the  greatest  fixed  point  of  a  function  Q 

An  alternative  might  be  an  inductive  definition  of  an  acceptability  relation: 

f='  as  the  least  fixed  point  of  the  function  Q. 

However,  in  Example  3.6  we  argued  that  this  might  be  inappropriate  and 
here  we  are  going  to  demonstrate  that  an  important  part  of  the  development 
of  the  previous  subsection  fails  for  the  least  fixed  point  of  Q. 


Proposition  3.16 

There  exists  e*  €  Exp  such  that  {(C,p)  |  (C,  p)  (='  e*}  is  not  a 
Moore  family. 


Proof  (sketch)  This  proof  is  rather  demanding  and  is  best  omitted  on  a  first 
reading.  To  make  the  proof  tractable  we  consider 


e*  =  t* 

t*  =  (fn  x  =>  (x*  x*)*)4  (fn  x  =>  (x*  x*)*)4 

and  take: 

Lab,  =  {£} 

Var*  =  {x} 

Term*  =  {t*,fn  x  =>  (x*  xe)l,xl  x*,x) 

IExpe  =  {t(  |  t  €  Term*} 

Val*  =  P({fn  x  =>  (xl  x*)*})  =  {0,  {fn  x  =>  (x'  x')'}} 
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This  is  in  line  with  Exercise  3.2  (and  the  development  of  Subsection  3.3.2)  and  as 
we  shall  see  the  proof  of  Proposition  3.13  is  not  invalidated. 

Next  let  Q  be  the  function  defined  by  Table  3.1  and  let  Q  be  in  the  domain  of  Q. 
The  condition 

Q  =  Q(Q) 

is  equivalent  to: 

Vt  €  Term*  :  V(C,p)  :  ((C,p)  Q  tl  iff  (C,p)  Q(Q)  f') 

By  considering  the  four  possibilities  of  t  €  Term*  jthis  is  then  equivalent  to  the 
conjunction  of  the  following  four  conditions  (where  (C,p)  is  universally  quantified): 

(C,p)Qxl  iff  p(x)C  C(£) 

(C,p)  Q  (fn  x  =>  (x*  x<)<)<  iff  (fn  x  =>  (x*  x*)*}  C  C(f) 

(C,p)  Q  (xl  xeY  iff  (C,p)Qxl  A 

C(f)  #  0  =>  ((C,p)  Q  (xe  x‘)e  A 
C(f)  C  p(x)) 

(C,p)Qtl  iff  (C,p)Q(  fnx=>(x‘x‘//A 

C(f)^0^  ((C,p)  Q  (xe  xe)1  A 

C(£)Cp(x)) 

Here  we  have  used  that  C(£)  0  implies  that  C(f)  =  {fn  x  =>  (x*  x,),|  as  follows 

from  the  definition  of  Val*  in  the  beginning  of  this  proof. 

The  conjunction  of  the  above  four  conditions  implies  the  conjunction  of  the  following 
four  conditions: 

(C  ,p)Qxl  iff  p(x)CC(£) 

(C,p)  Q  (fn  x  =>  (xl  x‘yy  iff  {fn  x  =>  (x*  x')'}  C  C(£) 

(C  ,p)Q{xlxly  iff  p(x)CC(£)A 

(C(f)/0  (C ,p)Q(xlxe)1)  A 

C(£)  C  p(x) 

(C ,p)Qti  iff  {fn  x  =>  (xe  xe)e}  C  C(£)  A 
(C ,p)  Q  {xl  xe)e  A 
C(£)  C  p(x) 

This  implication  can  be  reversed  and  this  shows  that  also  the  conjunct  of  the  above 
four  conditions  is  equivalent  to  Q  =  Q(Q). 

Using  that  p(x)  can  only  be  0  or  {fn  x  =>  (xl  x<)<},  and  similarly  for  C(f),  the 
above  four  conditions  are  equivalent  to  the  following: 

(C ,p)Qx'  iff  p(x)  C  C(£) 
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(C,  p)  Q  (fn  x  =>  (x'  x')*)'  iff  {fn  x  =>  (x*  x*)'}  =  C(£) 

(C,p)Q  (x'x1)1  iff  p(x)  =  C(£)  A 

(C(O#0  =>  (C,p)  Q  (xl  x1)1) 

(C,  p)  Q  ti  iff  {f n  x  =>  (x*  x')'}  =  C(£)  =  p(x)  A 
(C,p)  Q  (xe  x'Y 

It  follows  that  the  conjunct  of  the  above  four  conditions  is  once  more  equivalent  to 

Q  =  Q(Q)- 

The  crucial  case  in  the  definition  of  (C,p)  Q  e  is  for  e  =  (x*  x*)*  as  this  determines 
the  truth  or  falsity  of  all  other  cases.  We  shall  now  try  to  get  a  handle  on  the 
candidates  Q i, ■■■  ,Qn  for  satisfying  Qi  =  Q(Q,}.  Concentrating  on  the  condition 
for  (x*  x')'  it  follows  that  (C,  p)  Qi  (x<  x1)1  must  demand  that  C(£)  —  p(x).  Since 
each  of  C(£)  and  p(x)  can  only  be  {fn  x  =>  (x*  x*)*}  or  0  there  are  at  most  the 
following  four  candidates  for  Qp. 

(C  ,p)Qi(xV)'  iff  C(£)  =  p(x) 

(C  ,p)Q2(xex‘)‘  iff  C(£)  =  p(x)  =  0 
(C  ,p)Q3(xlxlY  iff  C(£)  =  p(x)/0 
(C,p)  Q4  (x*  x<)<  iff  false 

Verifying  the  condition 

V,C  ^  .  (  (C.p)  Qi  (**  x')‘  iff  p(x)  =  C(£)  A 

(C(£)#0  =*  (C,p)  Qi  (x‘ xlY) 

for  *  €  {1,2, 3, 4}  it  follows  that  Qi  and  Q2  satisfy  the  condition  whereas  Q3  and 
£?4  do  not. 

It  is  now  straightforward  to  verify  also  the  remaining  three  conditions  and  it  follows 
that: 

Qi  =  Q(Qi)  for  i  =  1,2 

This  means  that  Q 1  equals  (the  greatest  fixed  point  of  Q)  and  that  Qi  equals 
(the  least  fixed  point  of  Q).  One  can  then  calculate  that 

(C  ,p)Qi4  iff  C(£)  =  p(x)/0 
(C,p)  Qi  ti  iff  false 

and  this  shows  that 

{(C,p)  |  (C,p)  Qi  e*}  =  {(C,p)  |  C(£)  =  p(x)  =  {fn  x  =>  (x'  x')'}} 
which  is  a  singleton  set  and  in  fact  a  Moore  family,  whereas 

{(C,p)|(C,p)  Qi  e*}  =  0 


which  cannot  be  a  Moore  family  (since  a  Moore  family  is  never  empty).  This 
completes  the  proof.  ■ 
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3.3  Syntax  Directed  O-CFA  Analysis 

We  shall  now  show  how  to  obtain  efficient  realisations  of  O-CFA  analyses.  So 
assume  throughout  this  section  that  e*  €  Exp  js  the  expression^  interest 
and  that  we  want  to  find  a  “good”  solution  (C,j5)  satisfying  (C ,p)  j=  e*. 
This  entails  finding  a  solution  that  is  as  small  as  possible  with  respect  to  the 
partial  order  C  defined  in  Section  3.2  by: 

(Cupi)  E  (C2,?2)  iff  (W  :  Ct(i)  C  Ca(0)  A  (Vs  :  ft(*)  C  p2(x)) 

Proposition  3.13  shows  that  a  least  solution  does  exist;  however,  the  algo¬ 
rithm  that  is  implicit  in  the  proof  does  not  have  tractable  (i.e.  polynomial) 
complexity:  it  involves  enumerating  all  candidate  solutions,  determining  if 
they  are  indeed  solutions,  and  if  so  taking  the  greatest  lower  bound  with 
respect  to  the  others  found  so  far. 

An  alternative  approach  is  somehow  to  obtain  a  finite  set  of  constraints,  say 
of  the  form  Ihs  C  rhs  (where  Ihs  and  rhs  are  much  as  described  in  Section 
3.1),  and  then  take  the  least  solution  to  this  system  of  constraints.  The 
most  obvious  method  is  to  expand  the  formula  (C  ,p)  f=  e*  by  unfolding 
all  “recursive  calls” ,  using  memorisation  to  keep  track  of  all  the  expansions 
that  have  been  performed  so  far,  and  stopping  the  expansion  whenever  a 
previously  expanded  call  is  re-encountered. 

Three  phases.  We  shall  takea  more  direct  route  motivated  by  the  above 
considerations;  it  has  three  phases:'' 

(i)  The  specification  of  Table  3.1  is  reformulated  in  a  syntax  directed  man¬ 
ner  (Subsection  3.3.1). 

(ii)  The  syntax  directed  specification  is  turned  into  an  algorithm  for  con¬ 
structing  a  finite  set  of  constraints  (Subsection  3.4.1). 

(iii)  The  least  solution  of  this  set  of  constraints  is  computed  (Subsection 
3.4.2). 

This  is  indeed  a  common  phenomenon :  a  specification  “(=.4”  is  reformulated 
into  a  specification  “)=b”  ensuring  that 

(C,p)  | e*  •$=  (C,p)  |=b  e* 

so  that  “f =b"  is  a  safe  approximation  to  “(=4”  and  in  particular  the  best 
(i.e.  least)  solution  to  “f=B  e*”  is  also  a  solution  to  “1=^  e*”.  This  also 
ensures  that  all  solutions  to  “\=b”  are  semantically  correct  (assuming  that 
this  has  already  been  established  for  all  solutions  to  “|=a”)- 

If  additionally 

(C ,p)^e*  =>  (C ,p)^=Be* 
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then  we  can  be  assured  that  no  solutions  are  lost  and  hence  the  best  (i.e.  least) 
solution  to  “j=s  e*”  will  also  be  the  best  (i.e.  least)  solution  to  “|=x  e*”. 
However,  as  we  shall  see,  it  may  be  necessary  to  restrict  the  attention  to  only 
solutions  (C,  p)  satisfying  some  additional  properties  (e.g.  that  only  program 
fragments  of  e*  appear  in  the  range  of  C  and  p). 

3.3.1  Syntax  Directed  Specification 

In  reformulating  the  specification  of  “)=  e*”  into  a  more  computationally 
oriented  specification  “(=s  e*”  we  shall  ensure  that  each  function  body  is 
analysed  at  most  once  rather  than  each  time  the  function  could  be  applied. 
One  way  to  achieve  this  is  to  analyse  each  function  body  exactly  once  as  is 
done  in  the  syntax  directed  0-CFA  analysis  of  Table  3.5;  an  alternative  would 
be  to  analyse  only  reachable  function  bodies  and  we  refer  to  Mini  Project  3.1 
for  how  to  achieve  this.  In  Table  3.5  each  function  body  is  therefore  anal¬ 
ysed  in  the  relevant  clause  for  function  abstraction  rather  than  in  the  clause 
for  function  application;  thus  we  now  risk  analysing  unreachable  program 
fragments. 

Since  semantic  correctness  was  dealt  with  in  Section  3.2  there  is  no  longer  any 
need  to  consider  intermediate  expressions  and  consequently  our  specification 
of 

(C  ,p)  K  e 

in  Table  3.5  considers  ordinary  expressions  only.  We  shall  take  “(=s”  to  be 
the  largest  relation  that  satisfies  the  specification;  however,  given  the  syntax 
directed  nature  of  the  specification  there  is  in  fact  only  one  relation  that 
satisfies  the  specification  (see  Exercise  3.9).  Hence  it  would  be  technically 
correct,  but  intuitively  misleading,  to  claim  that  we  take  the  least  relation 
that  satisfies  the  specification. 

Example  3.17  Consider  the  expression  loop 

(let  g  =  (fun  f  x  =>  (f1  (fn  y  =>  y2)3)4)5 
in  (g6  (fn  z  =>  z7)8)9)10 

of  Example  3.4.  We  shall  verify  that  (Cip,/5jp)  (=s  loop  where  Qp  and  p\p  are 
as  in  Example  3.4.  Using  the  clause  [let],  it  is  sufficient  to  show 

(C|p,pip)  \=s  (fun  f  x  =>  (f1  (fn  y  =>  y2)3)4)5  (3.2) 

(C|P,  pip)  K  (g6  (fn  z  =>  z7)8)9  (3.3) 

since  we  have  Qp(5)  C  pjp(g)  and  Qp(9)  C  Qp(10).  To  show  (3.2)  we  use  the 
clause  [fun ]  and  it  is  sufficient  to  show 
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[con]  (C,  p)  j=a  cl  always 

[war]  (C,p)  f=,  xl  iff  p(x)  C  C(£) 

\fn]  (C,p)  (=,  (fn  x  =>  eo)1 

iff  {fn  x  =>  eo}  C  C(l)  A 
( C,p)  1=»  e0 

[fun]  (C,p)  (=*  (fun  /  x  =>  e0)1 

iff  {fun  f  x  =>  eo}  C  C(t )  A 

(C,p)  (=s  e0  A  {fun  f  x=>  e0}  C  p(/) 

[app]  (C,p)  K  (tiji7)* 

iff  (C,  p)  |=a  t['  A  (C,  p)  (=s  42  A 
(V(fn  x  =>  fg°)  e  C(^i)  : 

C(40  c  p(x)^  A  C(4)  C  C(l))  A 
(V(fun  /  x  =>  tl0°)  e  C(^i)  : 

C(f2)  C  £(*)  A  C(£0)  C  C(^)) 

[if]  (C,p)  f=a  (if  te0°  then  else  ti?)1 
iff  (C,p)K«o0A 

(Cip)  h»  f*1  a  (C,p)  [=5  t-f  a 
C(/i)  C  t{l)  A  C(/a)  c  C(0 
[let]  (C,p)  (=s  (let  x  =  tf*  in  tif)1 

iff  (C ,p)  ha  41  A  (C ,p)  ha  42  A 
C(h)  C  ?(x)  A  C(/2)  C  C(/) 

[op]  (C,p)  ha  (t{1  op  #)*  iff  (C,p)  (=a  A  (C,p)  ha  4* 

Table  3.5:  Syntax  directed  Control  Flow  Analysis. 

(C,p,P,p)  [=a  (f1  (fn  y  =>  y2)3)4 

since  f  G  Cip (5)  and  f  £  pip(f ).  Now  Cip (1)  =  {f}  so,  according  to  clause  [app] 
this  follows  from 

(Cip,  Pip)  ha  f 1 

(Cip,  Pip)  ha  (fn  y  =>  y2)3 

since  Qp(3)  C  pip(x)  and  Qp(4)  C  C|p(4).  The  first  clause  follows  from  [var] 
since  pip(f)  C  C|P(1)  and  for  the  last  clause  we  observe  that  idy  G  Qp(3)  and 
(Cip, pip)  h»  y2  ^  follows  from  pip(y)  C  Cip(2). 
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To  show  (3.3)  we  observe  that  Qp(6)  =  {f}  so  using  [app\  it  is  sufficient  to 
show 


(Cip,  Pip)  (=«  g6 

(Ctp.Pip)  l=s  (fn  z=>  z  ) 

since  Qp(8)  C  pjp(x)  and  Qp(4)  C  C|p(8).  This  is  straightforward  except  for 
the  last  clause  where  we  observe  that  id2  G  C|p(8)  and  (C|p,pip)  (=*  z7  as 
follows  from  pip(y)  C  C|P(7). 

Note  that  because  the  analysis  is  syntax  directed  we  have  had  no  need  for 
coinduction ,  unlike  what  was  the  case  in  Example  3.6.  ■ 

3.3.2  Preservation  of  Solutions 

The  specification  of  the  analysis  in  Table  3.5  uses  potentially  infinite  value 
spaces  although  this  is  not  really  necessary  (as  Exercise  3.2  demonstrates 
for  Table  3.1).  We  can  easily  restrict  ourselves  to  entities  occurring  in  the 
original  expression  and  this  forms  the  basis  for  relating  the  results  of  the 
analysis  of  Table  3.5  to  those  of  the  analysis  of  Table  3.1. 

So  let  Lab*  C  Lab  be  the  finite  set  of  labels  occurring  in  the  program  e*  of 


interest,  let  Var*  C  Var  be  the  finite  set  of  variables  occurring  in  e*  and  let 
Term*  be  the  finite  set  of  subterms  occurring  in  e*.  Define  (Cj,pj)  by: 

CJ(£)  =\ 

r  0 

[  Term* 

if  £  i  Lab* 
if  £  €  Lab* 

p*  0*0  =  | 

r  0 

[  Term* 

if  x  Var* 
if  x  G  Var* 

Then  the  claim 

(C,p)  E  (C*T, 

<pI) 

intuitively  expresses  that  (C,p)  is  concerned  only  with  subterms  occurring  in 

the  expression  e*;  obviously,  we  are  primarily  interested  in  analysis  results 
with  that  property.  Actually,  this  condition  can  be  “reformulated”  as  the 
technically  more  manageable 

(C,  p)  G  Cache*  x  Env* 

where  we  define  Cache*  =  Lab*  — »■  Val*,  Env*  =  Var*  — >  Val*  and  Val*  = 
■p(Term*). 

We  can  now  show  that  all  the  solutions  to  “|=s  e*”  that  are  “less  than” 
(C*  ,pj)  are  solutions  to  “(=  e*”  as  well: 
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Proposition  3.18 

If  (C ,p)  |=,  e*  and  (C ,p)  C  (Cj,pj)  then  (C ,p)  (=  e*. 


Proof  Assume  that  ( C,p)  |=,  e*  and  that  (C,p)  C  (Cj,pj).  Furthermore  let 
Exp,  be  the  set  of  expressions  occurring  in  e*  and  note  that 

Ve  €  Exp,  :  (C,  p)  \=,  e  (3.4) 

is  an  immediate  consequence  of  the  syntax  directed  nature  of  the  definition  of  (=3. 

To  show  that  (C,  p)  |=  e*  we  proceed  by  coinduction.  We  know  that  “f=”  is  defined 
coinductively  by  the  specification  of  Table  3.1,  i.e.  “j=  =  gfp(Q)"  where  Q  is  the 
function  (implicitly)  defined  by  Table  3.1.  Similarly,  we  know  that  “(=„  =  gfp(Qa)" 
where  Q,  is  the  function  (implicitly)  defined  by  Table  3.5. 

Next  write  (C',/?)  (=*  e'  for  (C',  /?)  =  (C,p)  A  e'  €  Exp,.  It  now  suffices  to  show 
(2.(h)nK)  c  s(hnK)  (3.5) 

because  then  “((=a  fl  [=*)  C  Q((=,  fl  [=*)”  follows  and  hence  by  conduction 
“([=,  fl  [=*)  C  f=”  and  since  (C,p)  [=3  e*  as  well  as  (C,p)  ^=*  e,  we  then  have  the 
required  (C,  p)  (=  e*. 

The  proof  of  (3.5)  amounts  to  a  comparison  of  the  right  hand  sides  of  Table  3.5 
and  Table  3.1:  for  each  clause  we  shall  assume  that  the  right  hand  side  of  Table 
3.5  holds  for  (C,  p,  e)  and  that  e  €  Exp,  and  we  shall  show  that  the  corresponding 
right  hand  side  of  Table  3.1  holds  when  all  occurrences  of  “|=”  are  replaced  by 

“K  n  (=*”. 

The  clauses  [con],  [war],  [i/j,  [let]  and  [op]  are  trivial  as  the  right  hand  sides  of  Tables 
3.5  and  3.1  are  similar  and  the  subterms  will  all  be  in  Exp,.  The  clauses  [/h]  and 
[fun]  are  straightforward  as  the  right  hand  sides  of  Table  3.5  imply  the  right-hand 
sides  of  Table  3.1.  Finally,  we  consider  the  clause  [app].  For  (fn  x  =>  tl0°)  e  C(fi  ) 
we  need  to  show  that  (C,p)  [=„  tj°;  but  since  (C,p)  C  (C J  ,pj)  this  follows  from 
(3.4).  For  (fun  f  x  =>  tl0°)  6  C(fi)  we  need  to  show  that  (C,  Jo)  ]=,  tl0°  and  that 
(fun  /  x  =>  to0)  G  p{f)\  the  first  follows  from  (3.4)  and  the  second  is  an  immediate 
consequence  of  (C,  p)  (=,  (fun  f  x  =>  t^0)1  (for  some  i)  that  again  follows  from 
(3.4).  . 

We  can  also  show  an  analogue  of  Proposition  3.13  for  the  syntax  directed 
analysis: 


Proposition  3.19^ 

{(C ,p)  £  Cache*  x  Env*  |  (C,  p)  [=„  e*}  is  a  Moore  family. 


i. 

f 


This  result  has  as  immediate  corollaries  that: 
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•  each  expression  e*  has  a  Control  Flow  Analysis  that  is  “less  than” 
(CJ.pJ).  and 

•  each  expression  e*  has  a  “least”  Control  Flow  Analysis  that  is  “less 
than”  (C 

This  means  that  the  properties  obtained  for  the  analysis  of  Table  3.1  in 
Subsection  3.2.3  also  hold  for  the  analysis  of  Table  3.5  with  the  additional 
restriction  on  the  range  of  the  analysis  functions.  In  particular,  any  analysis 
result  that  is  acceptable  with  respect  to  Table  3.5  (and  properly  restricted  to 
Cache*  x  Env*)  is  also  an  acceptable  analysis  result  with  respect  to  Table 
3.1.  The  converse  relationship  is  studied  in  Exercise  3.11  and  Mini  Project 
3.1. 

Proof  We  shall  write  (Cj ,pj )  also  for  the  greatest  element  of  Cache*  x  Env*. 
It  is  immediate  to  show  that 

(a)  (Cj,?J)Ke 

(b)  if  (Ci, pi)  e  and  (C2,P2)  K  e  then  ((Ci,pi)n  (^2,^2))  (=»  e. 

for  all  subexpressions  e  of  e*  by  means  of  structural  induction  on  e.  This  establishes 
(a)  and  (b)  also  for  e  =  e*.  Next  consider  some 

Y  C  {(C.p)  €  Cache*  x  Env,  |  ( C,p)  |=a  e*} 

and  note  than  one  can  write  Y  =  {(C^pi)  |  i  €  {1,  •  •  • ,  n}}  for  some  n  >  0  since 
Cache*  x  Env*  is  finite.  That 

\~]Y  €  {(C,p)  €  Cache,  x  Env,  ]  (C,p)  |=,  e*} 
then  follows  from  (a)  and  (b)  because  f]Y  =  (Cj ,pj )  n  (Ci,pi)  n  •  •  •  n  (C„,p„).  ■ 


3.4  Constraint  Based  0-CFA  Analysis 

We  ace  now  ready  to  consider  efficient  ways  of  finding  the  least  solution 
(C ,p)  such  that  (C,  p)  |=s  e*.  To  do  so  we  first  construct  a  finite  set  C*[e*J 
of  constraints  and  conditional  constraints  of  the  form 

Ihs  C  rhs  (3.6) 

{t}  C  rhs'  =$>  Ihs  C  rhs  (3.7) 

where  rhs  is  of  the  form  C(£)  or  r(x),  and  Ihs  is  of  the  form  C(£),  r(x),  or  {t}, 
and  all  occurrences  of  t  are  of  the  form  fn  x  =>  eo  or  fun  /  x  =>  e0.  To 
simplify  the  technical  development  we  shall  read  (3.7)  as 

({i}  C  rhs'  =>  Ihs )  C  rhs 


.1 


1 
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[con] 

C*[c*  ] 

=  0 

[war] 

caA 

=  {r(x)  C  C(0} 

IM 

C*[(fn 

x  =>  eo)^]  =  {{fn  x  =>  eo}  C  C(£)} 

U  C*[e0J 

[fun] 

C*[(fun  /  x  =>  eo)*]  =  {{fun  f  x  =>  e0}  C  C(£)} 

U  C*[e0]  U  {{fun  /  x  =>  e0}  C  r(/)} 

[m] 

42)1]  =  C*[tf]UC*[#] 

U  {{*}  C  C(£x)  =»  C(t2)  C  r(x) 

|  t  =  (fn  x  =>  to°)  £  Term*} 


U  {{t}  C  C(/i)  =*  C(£0)  C  C (i) 

|  t  =  (fn  x  =>  to°)  £  Term*} 
u  {{f}  C  C(*i)  =*  C(f2)  c  r(x) 

|  f  =  (fun  /  x  =>  to°)  €  Term*} 

U  {{f}  C  C(/i)  =►  C(£0)  C  C(0 

|  t  =  (fun  /  x  =>  to0)  €  Term*} 

[i/j  C*[(if  #  then  ^  else  <*»)<]  =  C*[f$° J  U  C*[f{‘J  U  C*[#J 

U  {C(/i)  C  C(/)} 
u{C(f2)  c  C(0} 

[let]  C*[(let  x  =  t[ 1  in  #)']  =  C*[t^]  U  £*[#] 

U{C(f1)Cr(x)}U{C(4)CC(Q} 

[op]  C*[(t{‘  op  #)*]  =  C*[iJ‘]  U  C*[f'2] 


Table  3.6:  Constraint  based  Control  Flow  Analysis. 


and  we  shall  write  Is  for  Ihs  as  well  as  {f}  C  rhs'  =>  Ihs. 

Informally,  the  constraints  are  obtained  by  expanding  the  clauses  defining 
(C,  p)  j=s  e*  into  a  finite  set  of  constraints  of  the  above  form  and  then  letting 
C*[e*]  be  the  set  of  individual  conjuncts.  One  caveat  is  that  all  occurrences 
of  “C”  are  changed  into  “C”  and  that  all  occurrences  of  “p”  are  changed  into 
“r”  to  avoid  confusion:  C(£)  will  be  a  set  of  terms  whereas  C(£)  is  pure  syntax 
and  similarly  for  p(x)  and  r(x). 

Formally,  the  constraint  based  0-CFA  analysis  is  defined  by  the  function  C* 
of  Table  3.6:  it  makes  use  of  the  set  Term*  of  subterms  occurring  in  the 
expression  e*  in  order  to  generate  only  a  finite  number  of  constraints  in  the 
clause  for  application;  this  is  justified  by  Propositions  3.18  and  3.19. 

If  the  size  of  the  expression  e*  is  n  then  it  might  seem  that  there  could 
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be  0(n2)  constraints  of  the  form  (3.6)  and  0(n4)  constraints  of  the  form 
(3.7).  However,  inspection  of  the  definition  of  C*  ensures  that  at  most  0(n) 
constraints  of  the  form  (3.6)  and  0(n2)  constraints  of  the  form  (3.7)  are  ever 
generated:  each  of  the  0(n)  constituents  only  generate  0(1)  constraints  of 
the  form  (3.6)  and  0(n)  constraints  of  the  form  (3.7). 

Example  3.20  Consider  the  expression 

((fn  x  =>  x1)2  (fn  y  =>  y3)4)5 

of  Example  3.7.  We  generate  the  following  set  of  constraints 

C*[((fn  x  =>  x1)2  (fn  y  =>  y3)4)5]  = 

{  {fn  x  =>  x1}  C  C(2), 
r«  C  C(l), 

(fn  y  =>  y3}  C  C(4), 
r(y)  c  C(3), 

{fn  x  =>  x1}  C  C(2)  =>  C(4)  C  r(x), 

{fn  x  =>  x1}  C  C(2)  =>  C(l)  C  C(5), 

{fn  y  =>  y3}CC(2)^C(4)Cr(y), 

{fn  y  =>  y3}  C  C(2)  =*  C(3)  C  C(5)  } 

where  we  use  that  fn  x  =>  x1  and  f n  y  =>  y3  are  the  only  abstractions  in 
Term*.  ■ 


3.4.1  Preservation  of  Solutions 


It  is  important  to  stress  that  while  (C ,p)  (=s  e*  is  a  logical  formula,  C*[e*|  is 
a  set  of  syntactic  entities.  To  give  meaning  to  the  syntax  we  first  translate 
the  “C”  and  “r”  symbols  into  the  sets  “C”  and  “p” : 

(C,j5)[CW]  =  C(i) 

(C,p)[r(x)]  =  p(x) 


To  deal  with  the  possible  forms  of  Is  we  additionally  take: 


(c,p)[mi 

(C,p)[{t}  C  rhs'  =>  l/is] 


{0 

f  (C,p)llhsl  if  {t}  C  (C,p)[rfcs'] 
1  0  otherwise 


Next  we  define  a  satisfaction  relation  (C,  p)  j=c  (Is  C  rhs )  on  the  individual 
constraints: 


* 


(C,p)  (=c  (Is  c  rhs)  iff  (C,p)[lsl  C  (C,p)[rhs] 
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This  definition  can  be  lifted  to  a  set  C  of  constraints  by: 

(C,  p)  f=c  C  iff  V(/s  C  rhs)  e  C  :  (C,  p)  \=c  (Is  C  rhs) 

We  then  have  the  following  result  showing  that  all  solutions  to  the  set  C*[e* ] 
of  constraints  also  satisfy  the  syntax  directed  specification  of  the  Control 
Flow  Analysis  and  vice  versa: 


Proposition  3.21 

(C,p)  f=s  e*  if  and  only  if  (C,p)  (=c  C*|[e*]. 


Thus  the  least  solution  (C,p)  to  (C ,p)  (=s  e*  equals  the  least  solution  to 

(C,p)  K  C*[e*J. 

Proof  A  simple  structural  induction  on  e  shows  that 
(C,p)t=,e  iff  (C,p)[=cC*[e] 

for  all  subexpressions  e  of  e*.  ■ 


3.4.2  Solving  the  Constraints 

We  shall  present  two  approaches  to  solving  the  set  of  constraints  C*[e*]. 
First  we  shall  show  that  finding  the  least  solution  to  C*[e*]  is  equivalent  to 
finding  the  least  fixed  point  of  a  certain  function;  straightforward  techniques 
allow  us  to  compute  that  in  time  0(n5)  when  the  size  of  the  expression  e* 
is  n.  Improvements  upon  this  are  possible,  but  to  obtain  the  best  known 
result  we  shall  consider  a  graph  representation  of  the  problem;  this  will  give 
us  a  0(n3)  algorithm.  This  is  indeed  a  common  phenomenon  in  program 
analysis:  syntax  directed  specifications  are  appropriate  for  correctness  con¬ 
siderations  but  often  they  need  to  be  “massaged”  in  order  to  obtain  efficient 
implementations . 

Fixed  point  formulation.  To  show  that  finding  the  solution  of  the 
set  C*[e*]  of  constraints  is  a  fixed  point  problem  we  shall  define  a  function 

F*  :  Cache*  x  Env*  Cache*  x  Env* 

and  show  that  it  has  a  least  fixed  point  lfp(Fi,)  that  is  indeed  the  least  solution 
whose  existence  is  guaranteed  by  Propositions  3.18  and  3.21. 

We  define  the  function  F*  by 

F*(C,p)  =  (F1(C,p),F2(C,p)) 
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where: 

Fi(C,m  =  U{(C,p)Ifa]|(faCCW)eC*[e*]} 

F2(C,p)(x)  =  U{(C,p)M!(/sCr(x))eC*[e*l} 

To  see  that  this  defines  a  monotone  function  it  suffices  to  consider  a  constraint 

Ihs'  C  rhs'  =>  Ihs  C  rhs 

in  C*[e*]  and  to  observe  that  Ihs  is  of  the  form  {t};  this  ensures  that 
(Ci,/5i)  C  (C2,p2)  implies  Fj(Ci,pi)  C  Fi(C2,p2)  (for  i  -  1,2)  because  if 
{t}  C  (Ci,pi)[r/i5']  then  also  {t}  C  (C2 , P2 ) f .  Since  Cache*  x  Env*  is 
a  complete  lattice  this  means  that  F*  has  a  least  fixed  point  and  it  turns  out 
to  be  the  least  solution  also  to  the  set  C*[e*J  of  constraints: 


Proposition  3.22 

W*)  =  r|{(C,p)  I  (C,p)  K  C*[e*]} 


Proof  It  is  easy  to  verify  that: 

E*(C,p)  C  (C,  p)  iff  (C,p)  (=c  C*[e,] 

Using  the  formula  Iip(/)  =  f|  {x  I  f(x)  £  x}  (see  Appendix  A)  the  result  then 
follows.  ■ 

If  the  size  of  e*  is  n  then  an  element  (C,  p)  of  Cache*  x  Env*  may  be  viewed 
as  an  0(n)-tuple  of  values  from  Val*.  Since  Val*  is  a  lattice  of  height  0(n) 
this  means  that  Cache*  x  Val*  has  height  0(n2)  and  hence  the  formula 

ifP(F*)  =  |jm  Frw 

may  be  used  to  compute  the  least  fixed  point  in  at  most  0(n2)  iterations. 
A  naive  approach  will  need  to  consider  all  0(n 2)  constraints  to  determine 
the  value  of  each  of  the  0(n )  components  of  the  new  iterant;  this  yields  an 
overall  0(n 5)  bound  on  the  cost. 

Graph  formulation.  An  alternative  method  for  computing  the  least 
solution  to  the  set  C*[e*J  of  constraints  is  to  use  a  graph  formulation  of 
the  constraints.  The  graph  will  have  nodes  C(£)  and  r(x)  for  l  €  Lab*  and 
x  £  Var*.  Associated  with  each  node  p  we  have  a  data  field  D[p]  that  initially 
is  given  by: 

Db]  =  {*  I  ({0  C  p)  £  C*[e*]} 

The  graph  will  have  edges  for  a  subset  of  the  constraints  in  C*[e*J;  each  edge 
will  be  decorated  with  the  constraint  that  gives  rise  to  it: 

•  a  constraint  p\  C  p2  gives  rise  to  an  edge  from  pi  to  p2,  and 
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p 

D[p] 

E[P] 

C(l) 

[id*  C  C(2)  =>  C(l)  C  C(5)] 

C(2) 

[idy  C  C(2)  =»  C(3)  C  C(5),  idy  C  C(2)  =»  C(4)  C  r(y), 

id*  C  C(2)  =►  C(l)  C  C(5),  id*  C  C(2)  =>  C(4)  C  r(x)] 

C(3) 

[idy  C  C(2)  =»  C(3)  C  C(5)] 

C(4) 

idy 

[idy  C  C(2)  =>>  C(4)  C  r(y),  id*  C  C(2)  =>  C(4)  C  r(x)] 

C(5) 

[] 

r(x) 

[rW  C  C(1)J 

r(y) 

[r(y)  C  C(3)j 

Figure  3.4:  Initialisation  of  data  structure  for  example  program. 


•  a  constraint  {t}  C  p  =>  P\  C  p2  gives  rise  to  an  edge  from  pi  to  P2  and 
an  edge  from  p  to  P2  • 

Having  constructed  the  graph  we  now  traverse  all  edges  in  order  to  propa¬ 
gate  information  from  one  D[pi]  to  another  D[p2].  We  make  certain  only  to 
traverse  an  edge  from  pi  to  p2  when  D[pi]  is  extended  with  a  term  not  previ¬ 
ously  there  (and  this  incorporates  the  situation  where  D[pi]  is  initially  set  to 
a  non-empty  set).  Furthermore,  an  edge  decorated  with  {f}  C  p  =>  pi  C  p2 
is  only  traversed  if  in  fact  t  €  D[p], 

To  be  more  specific  consider  the  algorithm  of  Figure  3.7.  It  takes  as  input  a 
set  C*[e*]  of  constraints  and  produces  as  output  a  solution  (C,  p)  G  Cache*  x 
Env*.  It  operates  on  the  following  main  data  structures: 

•  a  worklist  W  i.e.  a  list  of  nodes  whose  outgoing  edges  should  be  tra¬ 
versed; 

•  a  data  array  D  that  for  each  node  gives  an  element  of  Val*;  and 

•  an  edge  array  E  that  for  each  node  gives  a  list  of  constraints  from  which 
a  list  of  the  successor  nodes  can  be  computed. 

The  set  Nodes  consists  of  C(£)  for  all  l  in  Lab*  and  r(a:)  for  all  x  in  Var*. 

The  first  step  of  the  algorithm  is  to  initialise  the  data  structures.  The  second 
step  is  to  build  the  graph  and  to  perform  the  initial  assignments  to  the  data 
fields.  This  is  established  using  the  procedure  add(g,d)  that  incorporates  d 
into  D[</]  and  adds  q  to  the  worklist  if  d  was  not  part  of  D[g].  The  third  step 
is  to  continue  propagating  contributions  along  edges  as  long  as  the  worklist 
is  non-empty.  The  fourth  and  final  step  is  to  record  the  solution  in  a  more 
familiar  form. 
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INPUT:  C*[e*J 

OUTPUT:  (C  ,p) 

METHOD:  Step  1:  Initialisation 
W  :=  nil; 

for  q  in  Nodes  do  D[^]  :=  0; 
for  q  in  Nodes  do  E[q]  :=  nil; 

Step  2:  Building  the  graph 
for  cc  in  C*[e* ]  do 
case  cc  of 

{*}  Cp:  add(p,{f}); 

Pi  QP2 ■  E[pi]  :=  cons(cc,E[p!]); 

{t}Qp=>PiQ  P2- 

E[pi]  :=  cons(cc,E[px]); 

E[p]  :=  cons(cc,E[p]); 

Step  3:  Iteration 

while  W  ^  nil  do 

q  :=  head(W);  W  :=  tail(W); 
for  cc  in  E[<?]  do 
case  cc  of 

Pi  QP2-  add(p2,  D[pi]); 

.';{<}  QP=>PiQP2- 

if  t  e  D[p]  then  add(p2,  D[pi]); 

Step  4:  Recording  the  solution 

for  i  in  Lab*  do  C(£)  :=  D[C(£)]; 
for  x  in  Var*  do  p(x)  D[r(a:)]; 

USING:  procedure  add(g.d)  is 

if  (d  C  D [q]) 
then  D[g]  :=  D[g]  U  d ; 

W  :=  cons(g,W); 

Table  3.7:  Algorithm  for  solving  constraints. 

Example  3.23  Let  us  consider  how  the  algorithm  operates  on  the  ex¬ 
pression  ((fn  x  =>  x1)2  (fn  y  =>  y3)4)5  of  Example  3.20.  After  step  2  the 
data  structure  W  has  been  initialised  to 

W  =  [C(4),C(2)j, 

and  the  data  structures  D  and  E  have  been  initialised  as  in  Figure  3.4  where 
we  have  written  idx  for  {fn  x  =>  x1}  and  idy  for  {fn  y  =>  y3}.  The  algo- 
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w 

[C(4),C(2)] 

[r(x),C(2)] 

[C(1),C(2)] 

[C(5),C(2)] 

[C(2)] 

[] 

p 

D[p] 

D[p] 

D[p] 

D[p] 

D[p] 

D[p] 

mi 

mm 

idy 

idy 

fly  ?  I 
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id* 

jy  ft  | 

■ 

HI.  . 

Tm 

0 

§B  c  ■ 

idy 

idy 

idy 

idy 

idy 

||g|| 
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idy 

idy 

idy 

hj§i 

0 

idy 

idy 

idy 

idy 

idy 

Bsl 

0 

0 

0 

0 

0 

Figure  3.5:  Iteration  steps  of  example  program. 


rithm  will  now  iterate  through  the  worklist  and  update  the  data  structures  W 
and  D  as  described  by  step  3.  The  various  intermediate  stages  are  recorded 
in  Figure  3.5.  The  algorithm  computes  the  solution  in  the  last  column  and 
this  agrees  with  the  solution  presented  in  Example  3.5.  ■ 

The  following  result  shows  that  the  algorithm  of  Table  3.7  does  indeed  com¬ 
pute  the  solution  we  want: 


Proposition  3.24 

Given  input  C*[e*]  the  algorithm  of  Table  3.7  terminates  and  the 
result  (C  ,p)  produced  by  the  algorithm  satisfies 

(C)p)=n{(C',p')|(C',p')  KC*[e*]} 

and  hence  it  is  the  least  solution  to  C*  |e*|. 


Proof  It  is  immediate  that  steps  1,  2  and  4  terminate,  and  this  leaves  us  with 
step  3.  It  is  immediate  that  the  values  of  D[q]  never  decrease  and  that  they  can  be 
increased  at  most  a  finite  number  of  times.  It  is  also  immediate  that  a  node  q  is 
added  to  the  worklist  only  if  some  value  of  D[g]  actually  increased.  For  each  node 
placed  on  the  worklist  only  a  finite  amount  of  calculation  (bounded  by  the  number 
of  outgoing  edges)  needs  to  be  performed  in  order  to  remove  the  node  from  the 
worklist.  This  guarantees  termination. 

Next  let  (C'.p')  be  a  solution  to  (C',p')  f=c  C*[e*].  It  is  possible  to  show  that  the 
following  invariant 

S  Lab,  :  D[C(f)]  C  C'(£) 

Vx  €  Var*  :  D[r(x)]  C  j?(x) 
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is  maintained  at  all  points  after  step  1.  It  follows  that  (C,p)  C  (C',/?)  upon 
completion  of  the  algorithm. 

We  prove  that  (C,  p)  (=c  C,[e* ]  by  contradiction.  So  suppose  there  exists  cc  €  C*[e* ] 
such  that  (C,  p)  f=c  cc  does  not  hold.  If  cc  is  {t}  C  p  then  step  2  ensures  that  {f}  C 
D[p]  and  this  is  maintained  throughout  the  algorithm;  hence  cc  cannot  have  this 
form.  If  cc  is  pi  C  p2  it  must  be  the  case  that  the  final  value  of  D  satisfies  D[pi] 
0  since  otherwise  (C,p)  \=c  cc  would  hold;  now  consider  the  last  time  D[pi]  was 
modified  and  note  that  pi  was  placed  on  the  worklist  at  that  time  (by  the  procedure 
add);  since  the  final  worklist  is  empty  we  must  have  considered  the  constraint  cc 
(which  is  in  E[pi])  and  updated  D[p2]  accordingly;  hence  cc  cannot  have  this  form. 
If  cc  is  {<}  C  p  =>  pi  C  p2  it  must  be  the  case  that  the  final  value  of  D  satisfies 
D[p]  /  0  as  well  as  D[pi]  /  0;  now  consider  the  last  time  one  of  D[p]  and  D[pi]  was 
modified  and  note  that  p  or  pi  was  placed  on  the  worklist  at  that  time;  since  the 
final  worklist  is  empty  we  must  have  considered  the  constraint  cc  and  updated  D[p2] 
accordingly;  hence  cc  cannot  have  this  form.  Thus  (C,p)  |=c  cc  for  all  cc  G  C*[e*]. 

We  have  now  shown  that  (C,p)  [=c  C*[e„]  and  that  (C,p)  C  (C\  ’p1)  whenever 
(C',/7)  (=c  C*[e»].  It  now  follows  that 

(C,p)=n«e'-F  )i(C',p)  K  C.[e.]} 

as  required.  ■ 

The  proof  showing  that  the  algorithm  terminates  can  be  refined  to  show  that 
it  takes  at  most  0(n3)  steps  if  the  original  expression  e*  has  size  n.  To  see 
this  recall  that  C*[e*J  contains  at  most  0(n)  constraints  of  the  form  {t}  Cp 
or  Pi  Q  P2,  and  at  most  0{n2)  constraints  of  the  form  {t}  Q  p  ^  Pi  C  p2. 
We  therefore  know  that  the  graph  has  at  most  O(n)  nodes  and  0(n2)  edges 
and  that  each  data  field  can  be  enlarged  at  most  0(n)  times.  Assuming 
that  the  operations  upon  D[p]  take  unit  time  we  can  perform  the  following 
calculations:  step  1  takes  time  O(n),  step  2  takes  time  0(n2),  and  step  4 
takes  time  O(n);  step  3  traverses  each  of  the  0(n2)  edges  at  most  0(n )  times 
and  hence  takes  time  0(n3);  it  follows  that  the  overall  algorithm  takes  no 
more  than  0(n3)  basic  steps. 

Combining  the  three  phases.  From  Proposition  3.24  we  get  that 
the  pair  (C ,p)  computed  by  the  algorithm  of  Table  3.7  is  the  least  solution 
to  C[e*],  so  in  particular  (C, p)  (=c  C[e*|.  Proposition  3.21  shows  that  a 
solution  to  the  constraints  will  also  be  an  acceptable  analysis  result  for  the 
syntax  directed  specification,  hence  ( C,p )  }=„  e*.  Proposition  3.18  shows  that 
a  solution  that  only  involves  program  fragments  of  e*  and  that  is  acceptable 
for  the  syntax  directed  specification,  also  is  acceptable  for  the  abstract  spec¬ 
ification,  and  therefore  (C,  p )  (=  e*.  Thus  we  have  the  following  important 
corollary: 

Corollary  3.25  Assume  that  (C ,p)  is  the  solution  to  the  constraints 
C[e*|  computed  by  the  algorithm  of  Table  3.7;  then  (C ,p)  j=  e*.  ■ 
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It  is  not  the  case  that  any  (C,  p)  satisfying  (C,  p)  (=  e*  can  be  obtained  using 
the  above  approach  -  see  Exercise  3.11  and  Mini  Project  3.1. 

For  many  applications  it  is  the  ability  to  compute  the  least  (C  ,p)  satis¬ 
fying  (C ,p)  e*  that  is  of  primary  interest,  rather  than  the  ability  to 

check  (C ,p)  (=  e*  for  a  proposed  guess  (C ,/S).  However,  the  ability  to  check 
(C,  p)  |=  e*  is  indispensable  for  open  systems  where  the  environment  e.g.  pro¬ 
vides  a  library  to  be  used  with  e*.  When  analysing  and  optimising  e*  it  is 
(C  ,p)  that  expresses  the  assumptions  about  the  environment;  indeed  if  an 
existing  library  e  satisfies  ( C,p)  |=  e  for  the  (C,p)  j=  e*  used  to  optimise  e*, 
then  one  can  exchange  the  library  e  with  any  other  e'  as  long  as  (C,p)  \=  e1 
continues  to  hold,  and  the  optimisation  made  in  e*  will  continue  to  hold. 


3.5  Adding  Data  Flow  Analysis 

In  Section  3.1  we  indicated  that  our  Control  Flow  Analysis  could  be  extended 
with  Data  Flow  Analysis  components.  Basically,  this  amounts  to  extending 
the  set  Val  to  contain  other  abstract  values  than  just  abstractions.  We  shall 
first  see  how  this  can  be  done  when  the  data  flow  component  is  a  powerset 
and  next  we  shall  see  how  it  can  be  generalised  to  complete  lattices.  We  shall 
present  the  two  approaches  as  abstract  specifications  only  (in  the  manner  of 
Section  3.1). 

3.5.1  Abstract  Values  as  Powersets 

Abstract  domains.  There  are  several  ways  to  extend  the  value  domain 
Val  so  as  to  specify  both  Control  Flow  Analysis  and  Data  Flow  Analysis. 
A  particularly  simple  approach  is  to  use  a  set  Data  of  abstract  data  values 
(i.e.  abstract  properties  of  booleans  and  integers)  since  this  allows  us  to  define: 

v  £  Vafy  =  ■p(Term  U  Data)  abstract  values 

For  each  constant  c  £  Const  we  need  an  element  dc  £  Data  specifying  the 
abstract  property  of  c.  Similarly,  for  each  operator  op  £  Op  we  need  a  total 

function  _  _ 

op  :  Vafy  x  Vab  -4  Vab 

telling  how  op  operates  on  abstract  properties.  Typically,  op  will  have  a 
definition  of  the  form 

ui  op  v2  =  ^J{dop(di,  di)  |  di  £  Vi  Cl  Data,  d2  £  v?  Cl  Data} 

for  some  function  dop  :  Data  x  Data  -*  'P(Data)  specifying  how  the 
operator  computes  with  the  abstract  properties  of  integers  and  booleans. 
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Example  3.26  For  a  Detection  of  Signs  Analysis  we  take  Datas;gn  =  {tt, 
fF,  0,  +}  where  tt  and  ff  stand  for  the  two  truth  values  and  0,  and  +  for 
the  negative  numbers,  the  number  0,  and  the  positive  numbers,  respectively. 
It  is  then  natural  to  define  eft  rue  =  tt  and  dy  =  +  and  similarly  for  the  other 
constants.  Taking  +  as  an  example,  it  is  natural  to  base  its  definition  on  the 
following  table 


d+ 

tt 

ff 

- 

0 

+ 

tt 

0 

0 

0 

0 

0 

ff 

0 

0 

0 

0 

0 

- 

0 

0 

{"} 

{-} 

{“>  °>  +} 

0 

0 

0 

{-} 

{0} 

{+} 

+ 

0 

0 

{“.  +} 

W 

M 

and  similarly  for  the  other  operators.  ■ 

Acceptability  relation.  The  acceptability  relation  of  the  combined 
analysis  has  the  form 

(C,p)Ne 

and  is  presented  in  Table  3.8.  Compared  with  the  analysis  of  Table  3.1  the 
clause  [con]  now  records  that  dc  is  a  possible  value  of  c  and  the  clause  [op] 
makes  use  of  the  function  op  described  above.  In  the  case  of  [if  we  have 
made  sure  only  to  analyse  those  branches  of  the  conditional  that  the  analysis 
of  the  condition  indicates  the  need  for;  hence  we  can  be  more  precise  than 
in  the  pure  Control  Flow  Analysis  -  the  Data  Flow  Analysis  component  of 
the  analysis  can  influence  the  outcome  of  the  Control  Flow  Analysis.  In 
the  manner  of  Exercise  3.3  similar  improvements  can  be  made  to  many  of 
the  clauses  (see  Exercise  3.14)  and  thereby  the  specification  becomes  more 
flow-sensitive. 

Example  3.27  Consider  the  expression: 

(let  f  =  (fn  x  =>  (if  (x1  >  02)3  then  (fn  y  =>  y4)5 
else  (fn  z  =>  256)7)8)9 
in  ((f10  311)12  013)14)15 

A  pure  0-CFA  analysis  will  not  be  able  to  discover  that  the  else-branch  of 
the  conditional  will  never  be  executed  so  it  will  conclude  that  the  subterm 
with  label  12  may  evaluate  to  f n  y  =>  y4  as  well  as  fn  z  =>  25®  as  shown 
in  the  first  column  of  Figure  3.6.  The  second  column  of  Figure  3.6  shows  that 
when  we  combine  the  analysis  with  a  Detection  of  Signs  Analysis  (outlined 
in  Example  3.26)  then  the  analysis  can  determine  that  only  fn  y  =>  y4  is 
a  possible  abstraction  at  label  12.  Note  that  the  Detection  of  Signs  Analy¬ 
sis  (correctly)  determines  that  the  expression  will  evaluate  to  a  value  with 
property  {0}.  ■ 
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[con] 

(C,  P) 

\=d 

cl  iff  {dc}  C  C(£) 

[var] 

(C  ,P) 

\=d 

xl  iff  p(x)  C  C(£) 

\M 

(C  ,P) 

\=d 

(fn  x  =>  eo)e  iff  {fn  x  =>  eo}  C  C(£) 

[fun] 

(C,  p) 

N 

(fun  /  x  =>  eo)*  iff  {fun  /  x  =>  eo} 

[app] 

(C  ,p) 

\=d 

(tt  tty 

iff 

(C ,p)\=dtt  A  (C,p)  \=d  tt  A 

(V(fn  x  =>  tt)  €  C(^i)  : 

(^1  p)  ^=d  t0°  A 

C(l2)  c  p(x)^  A  C(4)  c  C(0)  A 
(V(fun  f  x  =>  $)  €  C(ii)  : 

(c,0N«f  a 

C(4»)  c  p(x)  A  C(4)  c  C(/)  A 

{fun  f  x  =>  to0}  Cp(f)) 


(C  ,P) 

\=d 

(if  tt 

then  tt  else  tt)1 

iff 

(C  ,P) 

N  te0°  A 

(dtrue 

e  C(4)  =*((C,p)  N 

(dful.e  e  C(£0)  =>  ((C,  p)  t=d  tt 

[let] 

(C,  P) 

\=d 

(let  x 

=  tt  in  ttY 

iff 

(C,jS) 

[ =d  t*1  A  (C,p)  [=<f  t22  A 

C(/i) 

C  p(x)  A  C(f2)  C  C(f) 

[op] 

(C  ,p) 

\=d 

(ft  op 

tty 

iff 

(C  ,p) 

1 =d  tf  A  (C,p)  \=<{  ty  A 

C(h)  op  C(/2)  C  C(/) 


A  C(/i)  C  C(£)))  A 
A  C(4)  c  C(0)) 


Table  3.8:  Abstract  values  as  powersets. 


The  proof  techniques  introduced  in  Section  3.2  should  suffice  for  proving  the 
correctness  of  the  analysis  with  respect  to  the  operational  semantics.  A  slight 
extension  of  the  algorithmic  techniques  presented  in  Sections  3.3  and  3.4  (and 
in  Mini  Project  3.1)  suffices  for  obtaining  an  implementation  of  the  analysis 
provided  that  the  set  Data  is  finite. 

Finally,  we  should  stress  that  a  solution  to  the  analysis  of  Table  3.8  does 
not  immediately  give  a  solution  to  the  ^analysis  of  Table  3.1.  More  precisely, 
(C, p)  | =d  e  does  not  guarantee  that  (C, /?)  f=  e  where  W  :  C'(£)  =  C(£)  fl 
Term  and  Vx  :  p'(x)  =  p(x)  fl  Term.  The  reason  is  that  the  Control  Flow 
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Section  3.1 

Subsection  3.5.1 

Subsection  3.5.2 

■ 

(C  ,P) 

(C  ,P) 

(C  ,p) 

(D  ,6) 

1 

0 

W 

0 

{+} 

2 

0 

{0} 

0 

{0} 

3 

0 

{«} 

0 

{«} 

4 

0 

{0} 

0 

{0} 

5 

{fn  y  =>  y4} 

{fn  y  =>  y4} 

{fn  y  =>  y4} 

0 

6 

0 

0 

0 

0 

7 

{fn  z  =>  256} 

0 

0 

0 

8 

{fn  y  =>  y4, 
fn  z  =>  256} 

{fn  y  =>  y4} 

{fn  y  =>  y4} 

0 

9 

{fn  x  =>  (•••)8} 

{fn  x  =>  {•••)8} 

{fn  x  =>  (■•*)8} 

0 

10 

{fn  x  =>  (•••)8} 

{fn  x  =>  (•••)8} 

{fn  x  =>  (•••)8} 

0 

11 

0 

{+} 

0 

w 

12 

{fn  y  =>  y4, 
fn  z  =>  256} 

{fn  y  =>  y4} 

{fn  y  =>  y4} 

0 

13 

0 

{0} 

0 

{0} 

14 

0 

{0} 

0 

{0} 

15 

0 

{0} 

0 

{0} 

f 

{fn  x  =>  (•••)8} 

{fn  x  => 

{fn  x  =>  (.-O8} 

0 

X 

0 

;.-{+} 

0 

W 

y 

0 

{0} 

0 

{0} 

Z 

0 

0 

0 

0 

Figure  3.6:  Control  Flow  and  Data  Flow  Analysis  for  example  program. 


Analysis  part  of  Table  3.8  is  influenced  by  the  Data  Flow  Analysis  part  in 
the  clause  [if:  if  for  example  the  abstract  value  of  the  condition  does  not 
include  dt™  then  the  then-branch  will  not  be  analysed. 


3.5.2  Abstract  Values  as  Complete  Lattices 

Abstract  domains.  Clearly  Vald  =  'P(TermUData)  is  isomorphic  to 
T’(Term)  x  'P(Data).  This  suggests  that  the  abstract  cache  C  :  Lab  -»  Valj 
could  be  split  into  a  term  component  and  a  data  component  and  similarly 
for  the  abstract  environment  p  :  Var  — )  Vald- 

Having  decoupled  ’P(Term)  and  'P(Data)  we  can  now  consider  replacing 
■p(Data)  by  a  more  general  collection  of  properties.  An  obvious  possibility 
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is  to  replace  T’(Data)  by  a  complete  lattice  L  and  perform  a  development 
closely  related  to  that  of  the  (forward)  Monotone  Frameworks  of  Chapter  2. 

So  let  us  define  a  monotone  structure  to  consist  of: 

•  a  complete  lattice  L ,  and 

•  a  set  T  of  monotone  functions  of  L  x  L  -»  L. 

An  instance  of  a  monotone  structure  then  consists  of  the  structure  (L,  T) 
and 

•  a  mapping  i.  from  the  constants  c  £  Const  to  values  in  L,  and 

•  a  mapping  /.  from  the  binary  operators  op  £  Op  to  functions  of  T. 

Compared  with  the  instances  of  the  Monotone  Frameworks  of  Section  2.3  we 
omit  the  flow  component  since  it  will  be  the  responsibility  of  the  Control 
Flow  Analysis  to  determine  this.  The  component  l  has  been  replaced  by  the 
mapping  i.  giving  the  extremal  value  for  all  the  constants  and  the  component 
/.  mapping  labels  to  transfer  functions  has  been  replaced  by  a  mapping  of 
the  binary  operator?  to  their  interpretation. 

Example  3.28  A  monotone  structure  corresponding  to  the  development 
of  Subsection  3.5.1  will  have  L  to  be  'P(Data)  and  T  to  be  the  monotone 
functions  of  'P(Data)  x  ^(Data)— >  'P(Data). 

An  instance  of  the  monotone  structure  is  then  obtained  by  taking 

i-c  —  {dc} 

for  all  constants  c  (and  with  dc  e  Data  as  above)  and 

fop{h,h)  =  \^}{dop(di,d2)  |  di  £  li,d^  £  h} 

for  all  binary  operators  op  (and  where  dop  :  Data  x  Data  — ►  7?  (Data)  is  as 
above).  ■ 


Example  3.29  A  monotone  structure  for  Constant  Propagation  Analysis 
will  have  L  to  be  Zj  x  ^({tt,  ff})  and  T  to  be  the  monotone  functions  of 
L  x  L  — y  L. 

An  instance  of  the  monotone  structure  is  obtained  by  taking  e.g.  =  (7, 0) 
and  ttrue  =  (JL,  {tt}).  For  a  binary  operator  such  as  +  we  can  take: 


Mh,h) 


{z\+Z2,®)  if  h  =  (zi,  •  •  -),h  —  (z2,  •  ■  ■), 
and  zi ,  Z2  €  Z 

<  (A,0)  if  h  =  (zi,---),h  =  (z2,---)> 

and  zi  =  i.  or  Z2  =  -L 
(T,0)  otherwise 
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We  can  now  define  the  following  abstract  domains 

v  £  Val  =  'P(Term)  abstract  values 

p  6  Env  =  Var  -» Val  abstract  environments 

C  €  Cache  =  Lab  ->  Val  abstract  caches 

to  take  care  of  the  Control  Flow  Analysis  and  furthermore 

d.  6  Data  =  L  abstract  data  values 

6  €  DEnv  =  Var  — >  Data  abstract  data  environments 

D  €  DCache  =  Lab  -» Data  abstract  data  caches 

to  take  care  of  the  Data  Flow  Analysis. 

Acceptability  relation.  The  acceptability  relation  now  has  the  form 

(C,D,p,  6)  ( =d  e 

and  it  is  defined  by  the  clauses  of  Table  3.9.  In  the  clause  [con]  we  see  that  the 
l.  component  of  the  instance  is  used  to  restrict  the  value  of  the  D  component 
of  the  analysis  and  in  the  clause  [op]  we  see  how  the  /.  component  is  used.  The 
clause  [if\  has  explicit  tests  for  the  two  branches  as  in  the  previous  approach 
thereby  allowing  the  Control  Flow  Analysis  to  benefit  from  results  obtained 
by  the  Data  Flow  Analysis  component.  As  in  the  previous  subsection,  similar 
improvements  can  be  made  to  many  of  the  other  clauses  so  as  to  produce  a 
more  flow-sensitive  analysis. 

Example  3.30  Returning  to  the  expression  of  Example  3.27  and  the  De¬ 
tection  of  Signs  Analysis  we  now  get  the  analysis  result  of  the  last  column  of 
Figure  3.6.  So  we  see  that  the  result  is  as  before.  ■ 

The  proof  techniques  introduced  in  Section  3.2  should  suffice  for  proving  the 
correctness  of  the  analysis  with  respect  to  the  operational  semantics.  A  slight 
extension  of  the  algorithmic  techniques  presented  in  Sections  3.3  and  3.4  (and 
in  Mini  Project  3.1)  suffices  for  obtaining  an  implementation  of  the  analysis 
provided  that  L  satisfies  the  Ascending  Chain  Condition  (as  is  the  case  for 
Monotone  Frameworks). 

Staging  the  specification.  Let  us  briefly  consider  the  following  al¬ 
ternative  clause  for  [if\  where  the  data  flow  component  cannot  influence  the 
control  flow  component  because  we  always  make  sure  that  that  the  analysis 
result  is  acceptable  for  both  branches: 

(C,  6 ,p,S)  \='D  (if  f£°  then  t[l  else  tl£)1 
iff  (C,  D,p,<5)  \='D  t0°  A 

(C,D ,p,S)  \='D  t[ 1  A  C(€i)  C  C(£)  A  D(/i)  C  D(£)  A 
(C,  D,  p,  6)  K,  #  A  C(£2)  C  C (i)  A  D(£>)  C  6(0 
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[con]  (C,  6 ,p,8)  | =d  cl  iff  tc  C  D(4 

[war]  (C,  D,p,  8)  (=£>  xl  iff  p{x)  C  C(4  A  8(x )  E  6(4 

L fn]  (C,  6 ,p,8)  (=o  (fn  x  =>  e0)/  iff  {fn  x  =>  e0}  C  C(4 

[fun]  (C,  D,p,  8)  | =d  (fun  /  x  =>  eo)*  iff  {fun  /  x  =>  eo}  C  C(4 

[app]  (C,  D,p,?)  \=D  (ij*  tjzY^ 

iff  (C,  6,  p,  8)  f=c  t['  A  (C,  6,  p,  8)  \=D  tl2  A 
(V(fn  z  »>  if)  G  C(4)  : 

(C.D.p.J)  |=£)  fg0  A 
C(4)  c  p(z)  A  6(4)  c  ?(*)  A 
C(4)  c  C(^A  6(4)  E  6(4)  A 
(V(fun  /  x  =>  if|  €  C(4)  : 

(C,  D,p,<S)  )=z>  A 

C(4)  c  p{x)  A  6(4)  E  Ax)  A 
C(4)  c  C(4  A  6(4)  E  6(4  A 

{fun  /  x  =>  t^0}  C  p(f)) 

[ij\  (C,  D,p,  8)  f (if  4q°  then  t[l  else  t t?)e 

iff  (C,  D,p,  J)  \=D  if  A  ^ 

(^true  E  D(4)  ^  (CtD,p,<5)  [=£)  t j1  A 
C(4)  C  C(£)A 
D(/0ED(0)a 

(^false  E  6(4)  =>  (C,  D,p,<S)  |=£)  if  A 

C(4)  c  C(Oa 
6(4)  E  6(4) 

[let]  (C,  D,p,(S)  (=d  (let  x  -  if  in  if)* 

iff  (C,6,£,<5)  \=D  t[ 1  A  (C,6,p,J)  |=D  if  A 
C(4)  E  p(x)  a  6(4)  E  $(*)  A 
C(4)  c  C(4  a  6(4)  E  6(4 

[op]  (C,D ,p,8)  \=d  (teY  opte22Y 

iff  (C,  6 ,p,8)  (=£?  if  A  (C,D,p,?)  \=D  if  A 
/oP(6(4),6(4))  e  6(4 


Table  3.9:  Abstract  values  as  complete  lattices. 
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Unlike  what  was  the  case  for  the  analyses  of  Tables  3.8  and  3.9,  a  solution  to 
the  analysis  modified  in  this  way  does  give  rise  to  a  solution  to  the  analysis 
of  Table  3.1;  to  be  precise  (C,  D,p,  6)  j='D  e  guarantees  (C ,p)  e. 

In  terms  of  implementation  this  modification  means  that  the  constraints  for 
the  control  flow  component  (C  and  p)  can  be  solved  first,  and  based  on  this 
the  constraints  for  the  data  flow  component  (D  and  S)  can  be  solved  next.  If 
both  sets  of  constraints  are  solved  for  their  least  solution  this  will  still  yield 
the  least  solution  of  the  combined  set  of  constraints. 

Example  3.31  Let  us  return  to  Example  3.30.  If  we  modify  the  clause 
for  [*/]  as  discussed  above  then  the  resulting  analysis  will  have  C  and  p  as  in 
the  column  for  the  pure  analysis  from  Section  3.1  and  D  and  S  will  associate 
slightly  larger  sets  with  some  of  the  labels  and  variables: 

6(6)  =  {+} 

6(14)  =  {0,+} 

6(15)  =  {0,+} 

6{z)  =  {0} 

This  analysis  is  less  precise  than  those  of  Tables  3.8  and  3.9:  it  will  only 
determine  that  the  expression  will  evaluate  to  a  value  with  the  property 
{0,+}.  ■ 


3.6  Adding  Context  Information 


The  Control  Flow  Analyses  presented  so  far  are  imprecise  in  that  they  cannot 
distinguish  the  various  instances  of  function  calls  from  one  another.  In  the 
terminology  of  Section  2.5  the  0-CFA  analysis  is  context-insensitive  and  in 
the  terminology  of  Control  Flow  Analysis  it  is  mono-variant. 

Example  3.32  Consider  the  expression: 


(let  f  =  (fn  x  =>  x1)2 
in  ((f3  f4)5  (fn  y  =>  y6)7)8)9 


analysis 

is  given  by  (CjC 

i.Pid): 

Qd(l) 

=  {fn  x  => 

x*,fn 

Cid(2) 

=  {fn  x  => 

x1} 

Cid(3) 

=  {fn  x  => 

x1} 

Cid(4) 

=  {fn  x  => 

x1} 

i 
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Cid(5)  = 

to 

>» 

A 

II 

>> 

X 

A 

II 

X 

rt 

«H 

Cid(6)  = 

{fn  y  =>  y6} 

Cid(7)  = 

{fn  y  =>  y6} 

Cid(8)  = 

{fn  x  =>  x1, fn  y  =>  y6} 

Cid(9)  = 

{fn  x  =>  x1,fn  y  =>  y6} 

Aid(f)  = 

{fn  x  =>  x1} 

Aid(x)  = 

{fn  x  =>  x*,fn  y  =>  y6} 

Ad(y)  = 

{fn  y  =>  y6} 

So  we  see  that  x  can  be  bound  to  fn  x  =>  x1  as  well  as  fn  y  =>  y6  and 
hence  the  overall  expression  (label  9)  may  evaluate  to  either  of  these  two 
abstractions.  However,  it  is  easy  to  see  that  in  fact  only  fn  y  =>  y6  is  a 
possible  result.  ■ 


To  get  a  more  precise  analysis  it  is  useful  to  introduce  a  mechanism  that 
distinguishes  different  dynamic  instances  of  variables  and  labels  from  one 
another.  This  results  in  a  context-sensitive  analysis  and  in  the  terminology 
of  Control  Flow  Analysis  the  term  poly-variant  is  used.  There  are  several 
approaches  to  how  this  can  be  done.  One  simple  possibility  is  to  expand  the 
program  such  that  the  problem  does  not  arise. 


Example  3.33  For  the  expression  of  Example  3.32  we  could  for  example 
consider 


let  fl  =  (fn  xl  =>  xl) 
in  let  f2  =  (fn  x2  =>  x2) 
in  (fl  f2)  (fn  y  =>  y) 

and  then  analyse  the  expanded  expression:  the  0-CFA  analysis  is  now  able 
to  deduce  that  xl  can  only  be  bound  to  fn  x2  =>  x2  and  that  x2  can  only 
be  bound  to  f n  y  =>  y  so  the  overall  expression  will  evaluate  to  fn  y  =>  y 
only.  ■ 


However,  a  more  satisfactory  solution  to  the  problem  is  to  extend  the  anal¬ 
ysis  with  context  information  allowing  it  to  distinguish  between  the  various 
instances  of  variables  and  program  points  and  still  analyse  the  original  ex¬ 
pression.  Examples  of  such  analyses  include  fc-CFA  analyses,  uniform  fc-CFA 
analyses  and  polynomial  fc-CFA  analyses  (for  k  >  0).  This  approach  is  clearly 
related  to  the  use  of  call-strings  in  interprocedural  analysis  as  studied  in  Sec¬ 
tion  2.5. 
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[con]  (C,  p)  f=|e  cl  always 

[var]  (C,  p)  f=f  xl  iff  p(x,  ce(x ))  C  C(£,  S) 

[ fn ]  (C,p)  f=r  (fn  x  =>  eo)*  iff  {(fn  x  =>  e0,ce0)}  C  C {£,6) 

where  ceo  =  ce  j  FV(fn  x  =>  e<>) 

[fun]  (C ,p)  hr  (fun  f  x  ->  eg)1  iff  {(fun  /  x  =>  eo,ceo)}  C  C (£,S) 

where  ceo  =  ce  |  FV(fun  /  x  =>  eo) 

[app]  (C,p)  \=f  (tj1  t%)1 

iff  (C,p)hr  A  (C,p)>r*22  A 

(V(fn  x  =>  te0°,ce0)  6  C(£i,S)  : 

(C,p)  h<s0°  tg°  A 

C(£2,S)  C  p(x,S0)  A  C(4,<50)  C  C(£,S) 
where  So  =  f<5,  £]k 
and  ce'Q  =  ce o[x  *->  <50])  A 
(V(fun  /  x  =>  tg°,ceo)  €  C(^i,<5)  : 

(C,p)  Koe“  <0°  A 

C(^,<$)  c  £(*,  Jo)  A  C(4,<5o)  C  C(M)  A 
{(fun  /  a;  =>  f$°,ce0)}  C  p(f,S0) 
where  6g  =  [<5,  i]k 
and  ce‘a  =  ce0[f  i->  50,x  >->•  <50]) 

[ if]  (C,p)  (=f  (if  fS°  then  <i'  else  *22)' 

iff  (c,p)  hr  *o°  a  (c ,p)  (=r  %  a  (c,?)  hr  4*  a 

C(£i,S)  C  C(M)  A  C(£2,<5)  C  C(£,<5) 

[let]  (C,p)  hr  (let  x  =  in  *22)< 

iff  (c,?)hr  t[i  a  (c,p)  hr'  <22  a 

C (£u6)  C  p(x,S)  A  C(£2,<5)  C  C{£,6) 
where  ce'  =  ce[x  t-+  5] 

m  (c,?)  He  (#  °p  ^  (c,  a)  hr  ^  a  (c,p)hr^2 


Table  3.10:  Control  Flow  Analysis  with  Contexts. 

3.6.1  Uniform  fc-CFA  Analysis 

Abstract  domains.  A  key  idea  is  to  introduce  context  to  distinguish 
between  the  various  dynamic  instances  of  variables  and  program  points. 
There  are  many  choices  concerning  how  to  model  contexts  and  how  they 
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can  be  modified  in  the  course  of  the  analysis.  In  a  uniform  k-CFA  analy¬ 
sis  (as  well  as  in  a  fc-CFA  analysis)  a  context  S  records  the  last  k  dynamic 
call  points;  hence  in  this  case  contexts  will  be  sequences  of  labels  of  length  at 
most  k  and  they  will  be  updated  whenever  a  function  application  is  analysed. 
This  is  modelled  by  taking: 

6  £  A  =  Lab-*  context  information 

Since  the  contexts  will  be  used  to  distinguish  between  the  various  instances 
of  the  variables  we  will  need  a  context  environment  to  determine  the  context 
associated  with  the  current  instance  of  a  variable: 

ce  £  CEnv  =  Var  -*  A  context  environments 

The  context  environment  will  play  a  role  similar  to  the  environment  of  the 
semantics;  in  particular,  this  means  that  we  shall  extend  the  abstract  values 
to  contain  a  context  environment: 

v  £  Val  =  P(Term  x  CEnv)  abstract  values 

So  in  addition  to  recording  the  abstractions  (fn  x  =>  e  and  fun  /  x  =>  e) 
we  will  also  record  the  context  environment  at  the  definition  point  for  the 
free  variables  of  the  term.  This  should  be  compared  with  the  Structural 
Operational  Semantics  of  Section  3.2  where  the  closures  contain  information 
about  the  abstraction  as  well  as  the  environment  determining  the  values  of 
the  free  variables  at  the  definition  point. 

The  abstract  environment  p  will  now  map  a  variable  and  a  context  to  an 
abstract  value: 

p  £  Env  =  (Var  x  A)  -» Val  abstract  environments 

Typically  we  will  use  a  context  environment  to  find  the  context  associated 
with  the  variable  of  interest  and  then  use  it  together  with  the  variable  to 
access  the  abstract  environment.  This  means  that  indirectly  we  get  the  effect 
of  having  local  abstract  environments  in  the  abstract  values  although  p  is  still 
a  global  entity  as  in  the  previous  sections. 

The  uniform  fc-CFA  analysis  differs  from  the  fc-CFA  analysis  in  performing 
a  similar  development  for  the  abstract  cache  that  now  maps  a  label  and  a 
context  to  an  abstract  value: 

C  £  Cache  =  (Lab  x  A)  — ¥  Val  abstract  caches 

Given  information  about  the  context  of  interest  we  can  determine  the  abstract 
value  associated  with  a  label.  Again  we  indirectly  get  the  effect  of  having  a 
cache  for  each  possible  context  although  it  is  still  a  global  entity.  (In  fc-CFA 
one  has  Cache  =  (Lab  x  CEnv)  -»  Val.) 
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Acceptability  relation.  The  acceptability  relation  for  uniform  k-CFA 
is  presented  in  Table  3.10.  It  is  defined  by  formulae  of  the  form 

(C,p)\=Te 

where  ce  is  the  current  context  environment  and  S  is  the  current  context. 
The  formula  expresses  that  (C,  p)  is  an  acceptable  analysis  of  e  in  the  context 
specified  by  ce  and  S.  The  clauses  for  the  various  constructs  are  very  much 
as  those  in  Table  3.1  and  will  be  explained  below. 

In  the  clause  [uar]  we  use  the  current  context  environment  ce  to  determine  the 
context  ce(x)  of  the  current  instance  of  the  variable  x  and  then  the  abstract 
value  of  the  variable  is  given  by  p(x,ce(x)).  The  current  context  is  5  so  we 
have  to  ensure  that  p(x,ce(x))  C  C(£,S). 

In  the  clause  [fn]  we  record  the  current  context  environment  as  part  of  the 
abstract  value  and  (as  in  the  Structural  Operational  Semantics  of  Table  3.2) 
we  restrict  the  context  environment  to  the  set  of  variables  of  interest  for  the 
abstraction.  The  clause  [fun]  is  similar. 

In  the  clause  [app]  we  analyse  the  two  subexpressions  using  the  same  context 
and  context  environment  as  the  composite  expression.  When  we  find  a  po¬ 
tential  abstract  value,  say  (fn  x  =>  tl0°,  ce o),  that  the  operator  may  evaluate 
to,  it  will  contain  a  local  context  environment  ceo  that  was  created  at  its 
definition  point.  When  analysing  tg°  we  will  have  passed  through  the  appli¬ 
cation  point  i,  so  the  current  context  will  be  updated  to  include  i  and  this 
will  also  be  the  context  associated  with  the  variable  x  in  the  updated  version 
of  the  context  environment  ce0  used  for  the  analysis  of  tl0° .  The  new  context 
is  \6,(f\k  which  (as  in  Section  2.5)  denotes  the  sequence  [6, £]  but  possibly 
truncated  (by  omitting  elements  on  the  left)  so  as  have  length  at  most  k.  In 
the  case  where  the  operator  has  the  form  (fun  /  x  =>  te0°,  ce0)  we  proceed  in 
a  similar  way  and  note  that  /  as  well  as  x  will  be  associated  with  the  new 
context  in  the  analysis  of  the  body  of  the  function. 

The  clauses  for  [*/],  [/e<]  and  [op]  are  fairly  straightforward  modifications  of 
those  of  Table  3.1;  however,  note  that  the  context  of  the  bound  variable  of 
the  let-construct  is  the  current  context  (as  no  application  point  is  passed). 
-  We  shall  dispense  with  proving  the  correctness  of  the  analysis  and  with 
showing  how  it  can  be  implemented. 

Example  3.34  We  shall  now  specify  a  uniform  1-CFA  analysis  for  the 
expression  of  Example  3.33: 

(let  f  =  (fn  x  =>  x1)2  in  ((f3  f4)5  (fn  y  =>  y6)7)8)9 

The  initial  context  will  be  A,  the  empty  sequence  of  labels.  In  the  course 
of  the  analysis  the  current  context  will  be  modified  at  the  two  application 
points  with  labels  5  and  8;  since  we  only  records  call  strings  of  length  at  most 
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one  the  only  contexts  of  interest  will  therefore  be  A,  5  and  8.  There  are  four 
context  environments  of  interest: 

ceo  =  [  ]  the  initial  (empty)  context  environment, 

cei  =  ceo[f  A]  the  context  environment  for  the  analysis  of  the  body 
of  the  let-construct, 

ce2  =  ceo[x  i->  5]  the  context  environment  used  for  the  analysis  of  the 
body  of  f  initiated  at  the  application  point  5,  and 
ce3  =  ceo[x  8]  the  context  environment  used  for  the  analysis  of  the 
body  of  f  initiated  at  the  application  point  8. 

Let  us  take  C'd  and  p|d  to  be: 

Cid(l,5)  =  {(fn  x  =>  x1,ce0)}  C[d(l,8)  =  {(fn  y  =>  y6,ce0)} 

C(d(2,A)  =  {(fn  x  =>  xx,ce0)}  C{d (3,  A)  =  {(fn  x  =>  xx,ceo)} 

C-d(4,A)  =  {(fn  x  =>  x1  ,ce0) }  C-d(5,A)  =  {(fn  x  =>  xx,ce0)} 

C'd (7, A)  =  {(fn  y  =>  y6,ce0)}  C-d(8,A)  =  {(fn  y  =>  y6,ce0)} 

C(d(9,A)  =  {(fn  y  =>  y6,ce0)} 

Pid(f-A)  =  {(fn  x  =>  xVeo)} 

Pid(x-5)  =  {(fn  x  =>  x\ce0)}  pfd (x> 8)  =  {(fn  y  =>  y6.ce0)} 

We  shall  now  show  that  this  is  an  acceptable  analysis  result  for  the  example 
expressions: 

(C[d,fld)  KC°  (let  f  =  (fn  x  =>  x1)2  in  ((f3  f4)5  (fn  y  =>  y3)^)3)3 
According  to  clause  [let],  it  is  sufficient  to  verify  that 

(C(d^d)  t=A°  x  =>  x1)2 
(Qd>%)  t=r  ((f3  f4)5  (fn  y  =>  y6)7)8 

because  C'd(2,A)  C  ^d(f,A)  and  Cfd(8, A)  C  C-d(9, A).  This  is  straightfor¬ 
ward  except  for  the  last  clause.  Since  C-d(5,A)  =  {(fn  x  =>  x1,ceo)}  it  is, 
according  to  [app],  sufficient  to  verify  that 

(4.%)  Kei  (f3  f4)5 

(4.%)  Kei  (fn  y  =>  y6)7 
(C(d,%)  K63  xl 

because  C'd(7,  A)  C  p(d(x, 8)  and  C-d(l,8)  C  C'd(8,  A).  This  is  straightforward 
except  for  the  first  clause.  Proceeding  as  above  we  see  that  C[d(3,  A)  =  {(fn 
x  =>  x1,ceo)}  and  it  is  sufficient  to  verify 
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(%,%)  Kei  f3 
(Qd,%)  Kei  f4 
(%,&)  Nr  x1 

because  C'd(4,  A)  C  pjd(x,  5)  and  C-d(l,  5)  C  C[d(5,  A).  This  is  straightforward. 

The  importance  of  this  example  is  that  it  shows  that  the  uniform  1-CFA 
analysis  is  strong  enough  to  determine  that  fn  y  =>  y6  is  the  only  result 
possible  for  the  overall  expression  unlike  what  was  the  case  for  the  0-CFA 
analysis  in  Example  3.32.  We  can  also  see  that,  since  p|d(y,  6)  =  0  for  all 
6  e  {A,  5, 8}  it  follows  that  f n  y  =>  y6  is  never  called  upon  a  function.  ■ 

The  resulting  analysis  will  have  exponential  worst  case  complexity  even  for 
the  case  where  k  =  1.  To  see  this  assume  that  the  expression  has  size  n  and 
that  it  has  p  different  variables.  Then  A  has  0(n)  elements  and  hence  there 
will  be  0(p  ■  n)  different  pairs  (x,  6)  and  0(n 2)  different  pairs  (1,6).  This 
means  that  (C ,p)  can  be  seen  as  an  0(n2)  tuple  of  values  from  Val.  Since 
Val  itself  is  a  powerset  of  pairs  of  the  form  (t,  ce)  and  there  are  0(n  ■  np ) 
such  pairs  it  follows  that  Val  has  height  0(n  ■  np).  Since  p  =  0(n)  we  have 
the  exponential  worst  case  complexity  claimed  above. 

This  should  be  contrasted  with  the  0-CFA  analysis  developed  in  the  previous 
sections.  It  corresponds  to  letting  A  be  a  singleton.  Repeating  the  above 
calculations  we  can  see  (C,  p)  as  an  0(p+n)  tuple  of  values  from  Val,  and  Val 
will  be  a  lattice  of  height  0(n).  In  total  this  gives  us  a  polynomial  analysis 
as  we  already  saw  in  Section  3.4. 

The  worst  case  complexity  of  the  uniform  fc-CFA  analysis  (as  well  as  the  k- 
CFA  analysis)  can  be  improved  in  different  ways.  One  possibility  is  to  reduce 
the  height  of  the  lattice  Val  using  the  techniques  of  Chapter  4.  Another 
possibility  is  to  replace  all  context  environments  with  contexts,  i.e.  to  have 
Val  =  T^Term  x  A);  clearly  this  will  give  a  lattice  of  polynomial  height. 
This  idea  is  closely  related  to  the  so-called  polynomial  k-CFA  analysis  where 
the  analogues  of  context  environments  are  forced  to  be  constant  functions, 
i.e.  to  map  all  variables  to  the  same  context.  In  the  case  of  polynomial  1-CFA 
the  analysis  is  of  complexity  0(n6). 

3.6.2  Interprocedural  Analysis  Revisited 

Let  us  conclude  this  section  by  comparing  the  above  development  with  that 
of  Section  2.5  where  we  considered  interprocedural  analysis  for  a  simple  im¬ 
perative  procedure  language. 

Recall  that  the  abstract  domain  of  interest  in  Section  2.5  has  the  form 


A  ->  L 
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where  A  is  the  context  information  and  L  is  the  complete  lattice  of  abstract 
values  of  interest.  For  each  label  £  the  analysis  will  determine  two  elements 
A0(£)  and  A,{£)  of  A  ->  L  describing  the  situation  before  and  after  the 
elementary  block  labelled  £  is  executed.  So  we  have 

Ao,At  :  Lab  — +  (A  — >  L) 

and  in  the  terminology  of  the  present  chapter  we  may  regard  these  functions 
as  abstract  caches.  There  is  no  analogue  of  the  abstract  environment  in 
Section  2.5  -  the  reason  is  that  the  procedure  language  is  so  simple  that  it  is 
not  needed:  the  abstract  environment  records  the  context  of  the  free  variables 
and  since  all  free  variables  in  the  procedures  are  global  variables  there  is  no 
need  for  this  component. 

We  can  now  reformulate  the  development  of  this  section  as  follows.  We  can 
take  the  abstract  domain  of  interest  to  be 

A  ~¥  T(Term  x  CEnv) 

and  reformulate  the  abstract  cache  and  the  abstract  environment  as  having 
the  functionalities: 

C  :  Lab  -»  A  ->  P(Term  x  CEnv) 
p  :  Var  A  — >  V^Term  x  CEnv) 

Thus  the  abstract  caches  of  the  interprocedural  analysis  and  the  uniform 
k- CFA  analysis  have  the  same  overall  functionality. 
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Control  Flow  Analysis  for  functional  languages.  Many  of 
the  key  ideas  for  Control  Flow  Analysis  have  been  developed  within  the 
context  of  functional  languages.  The  concept  of  k-CFA  analysis  seems  due 
to  Shivers  [121,  122,  123]  although  the  main  focus  was  on  0-CFA.  Other 
works  on  0-CFA-like  analyses  include  [128,  104,  41,  40].  The  ideas  behind 
fc-CFA  and  polynomial  k-CFA  analysis  were  further  clarified  in  [59]  that  also 
established  the  exponential  complexity  of  fc-CFA  analysis  for  k  >  0;  it  also 
related  a  form  of  Set  Based  Analysis  [53]  to  0-CFA.  The  uniform  k-CFA 
analyses  were  introduced  in  [94]  as  a  simplification  of  the  k-CFA  analyses; 
an  obvious  variation  over  this  is  to  record  the  set  of  the  last  k  distinct  call 
points.  Yet  another  variation  over  the  same  theme  is  Closure  Analysis ;  an 
early  and  often  neglected  development  may  be  found  in  [118]. 

To  the  extent  these  developments  go  beyond  0-CFA  they  establish  additional 
context  (called  mementoes,  tokens  or  contours)  for  representing  information 
concerning  the  dynamic  call  chain;  this  clearly  links  back  to  the  use  of  call 
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strings  in  Section  2.5.  The  formulation  of  the  analyses  (as  well  as  the  one 
presented  in  Table  3.1)  would  often  seem  to  be  more  appropriate  for  a  dy¬ 
namically  scoped  than  for  a  statically  scoped  language:  The  0-CFA  analy¬ 
sis  coalesces  information  about  variables  having  several  defining  occurrences 
even  if  they  differ  in  their  scope;  clearly  the  analysis  can  easily  be  modified 
so  that  it  more  directly  models  static  scope  (see  Exercise  3.7)  rather  than 
relying  on  no  variable  having  more  than  one  defining  occurrence. 

Another  way  to  establish  context  is  to  represent  the  static  call  chain.  This 
seems  first  to  be  described  by  [60]  as  part  of  their  so-called  “polymorphic 
splitting”  analysis.  A  more  general  set-up  was  formulated  in  [94]  that  also 
argued  for  the  need  to  base  abstract  specifications  on  coinductive  methods  - 
bearing  in  mind  that  coinductive  and  inductive  methods  may  coincide  as  in 
the  case  of  syntax  directed  specifications. 

Most  of  the  papers  cited  above  directly  formulate  a  syntax  directed  specifi¬ 
cation,  perhaps  proving  it  semantically  sound,  and  perhaps  showing  how  to 
obtain  constraints  so  as  to  obtain  an  efficient  implementation.  The  use  of  ab¬ 
stract  specifications  first  appeared  in  [60,  94]  and  has  the  advantage  of  being 
more  directly  applicable  to  open  systems  (that  allow  to  interface  with  the  li¬ 
brary  routines  provided  by  the  environment)  and  also  to  the  ideas  of  Abstract 
Interpretation  of  Chapter  4.  In  particular,  the  notion  of  reachability  suggests 
itself  rather  naturally  [14,  44],  it  becomes  clearer  how  to  integrate  ideas  from 
Abstract  Interpretation  into  Control  Flow  Analysis,  and  one  does  not  inad¬ 
vertently  restrict  oneself  to  closed- systems  only.  (The  notion  of  reachability 
is  considered  in  Mini  Project  3.1  which  is  based  on  [44].) 

Only  few  papers  [96]  discuss  the  interplay  between  the  choice  of  specification 
style  for  the  analysis  and  the  choice  of  semantics.  We  have  used  a  small-step 
Structural  Operational  Semantics  rather  than  a  big-step  semantics  in  order 
to  express  the  semantic  correctness  also  of  looping  programs.  We  have  used 
an  environment  based  semantics  in  order  to  ensure  that  we  do  not  “modify” 
the  bodies  of  functions  before  they  are  called,  so  that  function  abstractions 
can  meaningfully  be  used  in  the  value  domains  of  our  analysis  [96].  As  a 
consequence  we  have  had  to  introduce  intermediate  expressions  (closures  and 
bindings)  and  have  had  to  specify  the  abstract  analysis  also  for  intermediate 
expressions;  for  the  syntax  directed  specification  and  the  constraint  based 
analysis  this  was  not  necessary  given  that  semantic  correctness  had  already 
been  dealt  with.  Alternative  choices  are  clearly  possible  but  are  likely  to 
sacrifice  at  least  some  of  the  generality  offered  by  the  present  approach. 

Control  Flow  Analysis  for  other  language  paradigms.  An¬ 
other  main  application  of  Control  Flow  Analysis  has  been  for  object-oriented 
languages:  one  simply  tracks  objects  rather  than  functions  [1,  95,  105].  As 
a  reminder  of  the  close  links  between  Data  Flow  Analysis  ana  Control  Flow 
Analysis  we  should  also  mention  that  some  approaches  [139,  107]  are  closer  to 
the  presentation  of  Chapter  2.  A  common  theme  among  the  more  advanced 
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studies  is  the  incorporation  of  context  (related  to  fc-CFA)  and  an  abstract 
store  [102]  (to  deal  with  imperative  aspects  like  method  update).  To  increase 
the  precision,  local  versions  of  the  abstract  store  need  to  exist  at  all  program 
points,  and  abstract  reference  counts  are  needed  to  incorporate  a  “kill”  com¬ 
ponent  (in  the  manner  of  Chapter  2).  We  refer  to  the  above  literature  for 
further  details  of  how  to  formulate  such  analyses  and  how  to  choose  a  proper 
balance  between  precision  and  cost. 

Control  Flow  Analysis  for  concurrent  languages  has  received  relatively  little 
attention  [15].  However,  variations  of  the  techniques  presented  in  this  chapter 
have  been  used  to  analyse  functional  languages  extended  with  concurrency 
primitives  allowing  processes  to  be  created  dynamically  and  to  communicate 
via  shared  locations  or  channels  [58,  41,  44], 

In  this  book  we  do  not  consider  logic  languages.  However,  we  should  point 
out  that  Control  Flow  Analysis  also  has  applications  for  logic  languages  and 
that  set  based  analysis  was  first  developed  for  this  class  of  languages  [55,  56]. 

Set-Constraint  Based  Analysis.  Control  Flow  Analysis  is  just  one 
approach  to  program  analysis  where  the  use  of  constraints  pays  off.  In  this 
chapter  we  have  have  taken  the  following  approach:  (i)  first  we  have  given 
an  abstract  specification  of  when  a  proposed  solution  is  acceptable,  (ii)  then 
we  have  developed  an  algorithm  for  generating  a  set  of  constraints  expressing 
that  a  proposed  solution  is  acceptable,  and  (iii)  finally  we  have  solved  the  set 
of  constraints  for  the  least  solution.  For  the  solution  of  set  constraints  in  step 
(iii),  it  is  unimportant  how  the  Constraints  were  in  fact  obtained.  For  this 
reason,  it  is  often  said  that  set  constraints  allow  to  separate  the  specification 
of  an  analysis  from  its  implementation  and  that  set  constraints  are  able  to 
deal  with  forward  analyses  as  well  as  backward  analyses  and  indeed  mixtures 
of  these. 

Set  constraints  [55,  9]  have  a  long  history  [110,  64].  They  allow  to  express 
general  inclusions  of  the  form 

Si  C  S2 

where  set  expressions,  S,  set  variables,  V,  and  set  constructors,  C,  may  be 
built  as  follows: 

5  ::=  V  |  0  |  SiUS2\SinSa  \  C(Su  —  ,Sn) 

I  (Si  C  52)  =»  S2  |  (Si  t  0)  =*  S2  |  C-*(S)  \  ~>S  \  ■■■ 

V  ::=  X\Y\--- 

C  ::=  true  |  false  |  0  |  |  cons  |  nil  |  •  •  • 

Set  constraints  allow  to  consider  constructors  that  are  not  just  nullary  and 
this  allows  to  record  also  the  shape  of  data  structures,  e.g.  cons(Si,S2)Unil 
expresses  possibly  empty  lists  whose  heads  come  from  Si  and  whose  tails 
come  from  S2.  The  associated  projection  selects  those  terms  (if  any)  having 
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the  required  shape,  e.g.  cons-1  (5)  produces  the  heads  that  may  be  present 
in  S.  We  have  seen  conditional  constraints  before  and  it  turns  out  that 
projection  is  so  powerful  that  it  can  be  used  to  code  conditional  constraints. 
Finally,  it  is  sometimes  possible  to  explicitly  take  the  complement  of  a  set 
but  this  adds  to  the  complexity  of  the  development.  (It  means  that  solutions 
can  no  longer  be  guaranteed  using  Tarski’s  Theorem  and  sometimes  a  version 
of  Banach’s  Theorem  can  be  used  instead.) 

The  complexity  of  solving  a  system  of  set  constraints  depends  rather  dra¬ 
matically  on  the  set  forming  operations  allowed  and  therefore  many  versions 
have  been  considered  in  the  literature.  We  refer  to  [3,  108]  for  an  overview 
of  what  is  known  in  this  area;  here  we  just  mention  [19]  for  a  general  result 
and  [53,  5]  for  some  cubic  time  fragments. 

However,  it  is  worth  pointing  out  that  many  of  these  results  are  worst-case 
results;  benchmark  results  of  Jaganathan  and  Wright  [60]  shows  e.g.  that  in 
practice  a  1-CFA  analysis  may  be  faster  than  a  0-CFA  analysis  despite  the 
fact  that  the  former  has  exponential  worst-case  complexity  and  the  latter 
polynomial  worst-case  complexity.  The  reason  seems  to  be  that  the  0-CFA 
analysis  explores  most  of  its  polynomial  sized  state  space  whereas  the  1-CFA 
analysis  is  so  precise  that  it  only  explores  a  fraction  of  its  exponentially  sized 
state  space. 

The  basic  idea  behind  many  of  the  solution  procedures  for  set  constraints  is 
roughly  as  follows  [4]: 

1.  Dynamically  expand  conditional  constraints,  based  on  the  condition 
being  fulfilled,  until  no  more  expansion  is  possible. 

2.  Remove  all  conditional  constraints  and  combine  the  remaining  con¬ 
straints  to  obtain  the  least  solution. 

This  is  not  quite  the  algorithm  used  in  Section  3.4  where  we  were  only  in¬ 
terested  in  solving  a  rather  limited  class  of  constraints  for  0-CFA  analysis. 
When  generating  the  constraints  in  Table  3.6  we  were  able  to  “guess  a  uni¬ 
verse”  Term*  that  was  sufficiently  large  and  this  allowed  us  to  generate 
explicit  versions  of  the  conditional  constraints;  in  fact  a  superset  of  all  those 
to  be  considered  in  step  1  of  the  above  algorithm.  Therefore  our  subsequent 
constraint  solving  algorithm  in  Table  3.7  merely  needed  to  check  the  already 
existing  constraints  and  to  determine  whether  or  not  they  could  contribute 
to  the  solution.  In  practice,  the  above  “lazy”  algorithm  is  likely  to  perform 
better  than  the  “eager”  algorithm  of  Tables  3.6  and  3.7. 

A  final  note,  to  be  expanded  upon  in  Chapter  6,  is  that  also  state-of-the-art 
algorithms  for  Data  Flow  Analysis  work  by  internally  regarding  data  flow 
equations  as  presented  in  a  constraint  formulation.  This  is  yet  more  evidence 
of  the  close  connections  between  Data  Flow  Analysis,  Control  Flow  Analysis 
and  Set-Constraint  Based  Analysis. 
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Mini  Projects 

Mini  Project  3.1  Reachability  Analysis 

The  syntax  directed  analysis  of  Table  3.5  analyses  each  subexpression  of  e* 
“exactly  once”  rather  than  “at  most  once”  as  really  called  for.  In  this  mini 
project  we  shall  study  one  way  to  amend  this. 

The  idea  is  to  introduce  an  abstract  reachability  component 

R  €  Reach  =  Lab  — ►  ^({on}) 

and  to  modify  the  syntax  directed  analysis  to  have  a  relation  of  the  form 

(C,  p,  R)  K  e 

The  idea  is  that  fn  x  =>  te0°  has  {on}  C  R(f0)  if  and  only  if  the  function  is 
indeed  applied  somewhere,  and  that  the  “recursive  call”  (C,  p,  R)  f=s  tl0°  is 
performed  if  and  only  if  {on}  C  R(£0). 

1.  Modify  Table  3.5  to  incorporate  this  idea. 

2.  Show  the  following  analogue  of  Proposition  3.18:  If  (C,p,  R)  [='s  £**, 
{on}  C  R(4)  and  (C ,p)  C  (C J ,pj)  then  (C ,p)  |=  # . 

3.  Determine  whether  or  not  the  statements 

if  (C,  p)  |=  e*  then  (C,  p,  R)  \='s  e*  for  some  R 
if  (C ,p)  \=  e*  and  (C ,p)  C  (Cj,p*  )  then  (C,p,  R)  e*  for  some  R 
hold  in  general.  H 

Mini  Project  3.2  Data  Structures 

The  language  considered  so  far  only  includes  simple  data  like  integers  and 
booleans.  In  this  mini  project  we  shall  extend  the  language  with  more  general 
data  structures: 

e  ::=•••  |  C(ei,”‘,en)*  |  (case  eo  of  C(x i, •••,£„)  =>  e\  or  x  ->  e-i)1 

Here  C  €  Constr  denotes  an  n-ary  data  constructor.  A  data  element  is 
constructed  by  C(ei,  •  •  • ,  en):  it  has  tag  C  and  its  components  are  the  values 
of  ei,***,en.  The  case  construct  will  first  determine  the  value  Vo  of  eo,  if 
v0  has  the  tag  C  then  xi ,  •  •  • ,  xn  will  be  bound  to  the  components  of  v0  and 
e\  is  evaluated.  If  vq  does  not  have  tag  C  then  x  is  bound  to  vq  and  ei  is 
evaluated. 

As  an  example  we  may  have  Constr  =  {cons,  nil}  so  we  have  the  following 
expression  (omitting  labels)  for  reversing  a  list: 
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let  append  =  fun  app  xs  =>  fn  ys  => 

case  xs  of  cons(z,zs)  =>  cons (z, app  zs  ys) 
or  xs  =>  ys 

in  fun  rev  xs  =>  case  xs  of  cons(y,ys)  => 

append  (rev  ys)  (cons(y ,nil())) 
or  xs  =>  nil() 

To  specify  a  0-CFA  analysis  for  this  language  we  shall  take 

Val  =  'P(TermU  {C(t i,  •  •  •  ,in)  \  C  £  Constr,£i,-  •  •  ,in  G  Lab}) 

As  before  the  terms  of  interest  are  fn  x  =>  eo  and  fun  f  x  =>  e  o  for  recording 
the  abstractions.  The  new  contribution  is  a  number  of  elements  of  the  form 
C(£\,-  •  ■ ,  tn)  denoting  a  data  element  C(v x,  ••■,«„)  whose  i’th  component 
might  have  been  created  by  the  expression  at  program  point  li- 

1.  Develop  a  syntax  directed  analogue  of  the  analysis  in  Table  3.5. 

2.  Modify  the  constraint  generation  algorithm  of  Table  3.6  to  handle  the 
new  constructs  and  make  the  necessary  changes  to  the  constraint  solv¬ 
ing  algorithm  of  Table  3.7. 

For  the  more  ambitious:  are  there  any  difficulties  in  developing  an  abstract 
analogue  of  the  analysis  in  Table  '3:1?  ■ 


Mini  Project  3.3  A  Prototype  Implementation 


In  this  mini  project  we  shall  implement  the  pure  0-CFA  analysis  considered 
in  Section  3.3.  As  implementation  language  we  shall  choose  a  functional 
language  such  as  Standard  ML  or  Haskell.  We  can  then  define  a  suitable 
data  type  for  FUN  expressions  as  follows: 


type  var 
type  label 
datatype  const 
datatype  exp 
and  term 


=  string 
=  int 

=  Num  of  int  |  True  |  False 

=  Label  of  term  *  label 

=  Const  of  const  |  Var  of  var 
|  Fn  of  var  *  exp  |  Fun  of  var  *  var  *  exp 
|  App  of  exp  *  exp  |  If  of  exp  *  exp  *  exp 

|  Let  of  var  *  exp  *  exp  |  Op  of  string  *  exp  *  exp 


Now  proceed  as  follows: 


Exercises 


199 


1 .  Implement  the  constraint  based  control  flow  analysis  of  Section  3.4;  this 
includes  defining  an  appropriate  data  structure  constraints  for  (condi¬ 
tional)  constraints. 

2.  Implement  the  graph  based  algorithm  of  Section  3.4  for  solving  con¬ 
straints;  this  involves  choosing  appropriate  data  structures  for  the  work- 
list  and  the  two  arrays  used  by  the  algorithm. 

For  the  more  ambitious:  generalise  your  program  to  perform  some  of  the  more 
advanced  analyses,  e.g.  by  incorporating  data  flow  information  or  context 
information.  ■ 


Exercises 

Exercise  3.1  Consider  the  following  expression  (omitting  labels): 

let  f  =  fn  x  =>  x  1 
in  let  g  =  fn  y  =>  y+2 

in  let  h  =  fn  z  =>  z+3 
in  (f  g)  +  (f  h) 

Add  labels  to  the  program  and  guess  an  analysis  result.  Use  Table  3.1  to 
verify  that  it  is  indeed  an  acceptable  guess.  ■ 

Exercise  3.2  The  specification  of  the  Control  Flow  Analysis  in  Table  3.1 
uses  potentially  infinite  value  spaces  and  this  is  not  really  necessary.  To  see 
this  choose  some  expression  e*  G  Exp  that  is  to  be  analysed.  Let  Var*  C  Var 
be  the  finite  set  of  variables  occurring  in  e*,  let  Lab*  C  Lab  be  the  finite  set 
of  labels  occurring  in  e*,  and  let  Term*  be  the  finite  set  of  subterms  of  e*. 
Next  define 

v  G  Val*  =  P(Term*) 

p  G  Env*  =  Var*  ->  Val* 

C  G  Cache*  =  Lab*  -» Val* 

and  note  that  these  value  spaces  are  finite.  Show^  that  the  specification  of 
the  analysis  in  Table  3.1  still  makes  sense  when  (C,p)  is  restricted  to  be  in 
Cache*  x  Env*.  ■ 

Exercise  3.3  Modify  the  Control  Flow  Analysis  of  Table  3.1  to  take  ac¬ 
count  of  the  left  to  right  evaluation  order  imposed  by  a  call-by-value  se¬ 
mantics:  in  the  clause  [app]  there  is  no  need  to  analyse  the  operand  if  the 
operator  cannot  produced  any  closures.  Try  to  find  a  program  where  the 
modified  analysis  accepts  analysis  results  (C ,p)  rejected  by  Table  3.1.  ■ 
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Exercise  3.4  So  far  we  have  defined  “(C,p)  is  an  acceptable  solution  for 
e”  to  mean  that 

(C,p)|=e  (3-8) 

but  an  alternative  condition  is  that 

3(0',?)  :  (C ',?)  1=  e  A  (C ',?)  C  (C ,p)  (3.9) 

Show  that  (3.8)  implies  (3.9)  but  not  vice  versa.  Discuss  which  of  (3.8)  or 
(3.9)  is  the  preferable  definition.  ■ 

Exercise  3.5  Consider  an  alternative  specification  of  the  analysis  in  Table 
3.1  where  the  condition 


(fun  f  x=>  to0)  6  p(f) 


in  [ app ]  is  replaced  by 

C(M  C  p(f) 

also  in  [ app ].  Show  that  the  proof  of  Theorem  3.10  can  be  modified  accord¬ 
ingly.  Discuss  the  relative  precision  of  the  two  analyses.  ■ 

Exercise  3.6  Reconsider  our  decision  to  use  Val  =  T’(Term)  and  con¬ 
sider  using  Val  =  T’(Exp)  instead.  Show  that  the  specification  of  the  Con¬ 
trol  Flow  Analysis  may  be  modified  accordingly  but  that  then  Fact  3.11  (and 
hence  the  correctness  result)  would  fail.  ■ 

Exercise  3.7  The  operational  semantics  allow  us  to  rename  bound  vari¬ 
ables  without  changing  the  semantics;  this  is  in  accord  with  the  language 
being  statically  scoped  (or  lexically  scoped)  rather  than  dynamically  scoped. 
As  an  example 


((fn  x  =>  x1)2  (fn  y  =>  y3)4)5  =0  ((fn  x  =>  x1)2  (fn  x  =>  x3)4)5 


and  clearly  the  two  programs  have  the  same  semantics. 

However,  renaming  bound  variables  changes  the  acceptability  of  a  solution  as 
well  as  influences  the  precision  of  the  analysis  specified  in  Table  3.1.  Develop 
an  abstract  specification  of  a  0-CFA  analysis  that  is  more  faithful  to  the  static 
scoping  than  that  of  Table  3.1;  it  should  agree  with  the  specification  of  Table 
3.1  for  expressions  that  do  not  have  multiple  defining  occurrences.  ■ 

Exercise  3.8  In  Section  3.2  we  equipped  Fun  with  a  call-by-value  se¬ 
mantics.  An  alternative  would  be  to  use  a  call-by-name  semantics.  It  can  be 
obtained  as  a  simple  modification  of  the  semantics  of  Tables  3.2  and  3.3  by 
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allowing  the  environments  p  €  Env  to  map  variables  to  intermediate  terms 
(and  not  just  values),  by  deleting  the  rules  [app2]  and  [letp]  and  then  make 
some  obvious  modifications  to  the  axioms  [var],  [appfn],  [ appfun ]  and  [let{]\ 
in  the  case  of  [t/ar]  we  will  take: 

p  I-  xl  -4  it1  if  x  £  dom(p)  and  it  =  p{x) 

Complete  the  specification  of  the  call-by-name  semantics  of  Fun  and  show 
that  the  correctness  result  (Theorem  3.10)  still  holds  for  the  analysis  of  Table 
3.1. 

What  does  that  tell  us  about  the  precision  of  the  analysis?  ■ 

Exercise  3.9  Let  (='„  and  f="  be  two  relations  satisfying  the  specification 
of  Table  3.5.  Show  that 


(C,j5)K  eiff(C,p)K  e 

by  structural  induction  on  e.  m 

Exercise  3.10  Consider  Proposition  3.18  and  determine  whether  or  not 
the  statement 

if  (C ,p)  e*  then  (C ,p)  (=  e* 

holds  in  general.  -  ■ 

Exercise  3.11  Give  an  example  showing  that  both  of  the  statements 
if  (C,  j5)|=e*  then  (C,  p)  e* 

if  (C ,p)  |=  e*  and  (C ,p)  C  (Cj,pj)  then  (C ,p)  \= ,  e* 
fail  in  general.  ■ 

Exercise  3.12  Give  a  direct  proof  of  the  correctness  of  the  syntax  di¬ 
rected  analysis  of  Table  3.5,  i.e.  establish  an  analogue  of  Theorem  3.10.  This 
involves  first  extending  the  syntax  directed  analysis  to  the  bind-  and  close- 
constructs  and  next  proving  that  if  p  TZ  p,  p  I-  ie  ->  ie'  and  (C,  p)  j=„  ie  then 
also  (C,p)  (=»  ie'.  m 

Exercise  3.13  Consider  the  system  C^Ie*]  that  contains  a  constraint 

Isi  U  •  •  •  U  lsn  =  rhs 
whenever  C*[e*]  contains  the  n  >  1  constraints 
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Show  that 

(C ,p)  1 =c  C=[e*  1  implies  (C,p)  f=c  C*[e*] 
where  ( C,p)  j=c  (Is  =  rhs)  is  defined  in  the  obvious  way.  Also  show  that 

(C,p)  \=c  C*[e»]  implies  (C ,p)  \=c  C=[e*J 
holds  in  the  special  case  where  (C ,p)  is  least  such  that  (C ,p)  (=c  ■ 

Exercise  3.14  Use  the  ideas  of  Exercise  3.3  to  develop  an  improvement 
of  Table  3.8  where  expressions  are  only  analysed  when  absolutely  needed. 
Next  develop  a  syntax  directed  analysis  using  the  same  ideas.  Discuss  the 
relationship  between  the  two  specifications:  are  they  more  closely  related 
than  is  the  case  for  f=  and  (=,  of  Table  3.1  and  3.5  (see  Exercises  3.10  and 
3.11)?  ■ 

Exercise  3.15  Modify  the  abstract  specification  of  the  uniform  k-CFA 
analysis  so  that  it  does  not  record  the  last  k  function  calls  but  the  last 
k  changes  function  calls:  if  the  calling  sequence  is  [1,2, 2, 1,1]  then  2-CFA 
records  [1,1]  but  the  modified  analysis  records  [2,1].  Discuss  which  of  the  two 
analyses  (say  for  k  =  2)  is  likely  to  be  most  useful  in  practice.  ■ 

Exercise  3.16  Let  us  consider  a  language  of  first-order  recursion  equation 
schemes:  the  programs  have  the  form 

define  £•*  in  e* 

where  D*  is  a  sequence  of  function  definitions  of  the  form: 

/(*)■  e 

Here  /  is  a  function  name,  x  is  the  formal  parameter  and  e  is  the  body  of 
the  function;  the  functions  defined  in  D  may  be  mutually  recursive  and  the 
parameter  mechanism  is  call-by-value.  The  expressions  are  given  by 

e  ::=  tl 

t  ::=  c  |  x  |  /  e  |  if  e<j  then  e\  else  e-i  |  ei  op  e2 

where  c  G  Const  and  op  G  Op  as  before;  we  shall  assume  that  /  and  x 
belong  to  distinct  syntactic  categories.  As  an  example  we  may  define  the 
Fibonacci  function  by  the  following  expression  (omitting  labels): 

define  fib(z)  =  if  z<3  then  0 

else  fib  (z-1)  +  fib  (z-2) 

in  f ib  x 
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Define  a  uniform  &-CFA  analysis  for  this  language.  For  k  =  0  and  k  =  1 
compare  the  development  with  that  for  the  procedure  language  in  Section 
2.5.  ■ 

Exercise*  3.17  In  Section  3.6  we  showed  how  to  extend  the  Control  Flow 
Analysis  with  contest  similar  to  the  call  strings  of  Section  2.5.  Investigate 
the  possibility  of  performing  a  similar  development  based  on  the  assumption 
sets  of  Section  2.5.  ■ 
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Chapter  4 


Abstract  Interpretation 


The  purpose  of  this  chapter  is  to  convey  some  of  the  essential  ideas  of  Ab¬ 
stract  Interpretation.  We  shall  mainly  do  so  in  a  programming  language 
independent  way  and  thus  focus  on  the  design  of  the  property  spaces,  the 
functions  and  computations  upon  them,  and  the  relationships  between  them. 

We  first  formulate  a  notion  of  correctness  for  a  restricted  class  of  analyses 
as  this  will  allow  us  to  motivate  better  some  of  the  key  definitions  in  the 
development.  Then  we  cover  the  widening  and  narrowing  techniques  that  can 
be  used  to  obtain  approximations  of  the  least  fixed  point  and  for  limiting  the 
number  of  computation  steps  needed.  Next  we  consider  Galois  connections 
and  Galois  insertions  that  allow  a  costly  space  of  properties  to  be  replaced 
with  one  that  is  less  costly.  Galois  connections  can  be  constructed  in  a 
systematic  way  and  can  be  used  to  induce  one  specification  of  an  analysis 
from  another. 


4.1  A  Mundane  Approach  to  Correctness 

To  set  the  scene,  imagine  some  programming  language.  Its  semantics  iden¬ 
tifies  some  set  V  of  values  (like  states,  closures,  double  precision  reals)  and 
specifies  how  a  program  p  transforms  one  value  V\  to  another  v2\  we  may 
write 

p\-  Vi  ^  V2  (4.1) 

for  this  without  committing  ourselves  to  the  details  of  the  semantics  and 
without  necessarily  imposing  determinacy  (that  p  b  v\  v2  and  p  b  ui  v2 
imply  v2  =  u3). 

In  a  similar  way,  a  program  analysis  identifies  the  set  L  of  properties  (like 
shapes  of  states,  abstract  closures,  lower  and  upper  bounds  for  reals)  and 
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specifies  how  a  program  p  transforms  one  property  li  to  another  l2\  we  may 
write 


phh>l2  (4.2) 

for  this  without  committing  ourselves  to  the  method  used  for  specification 
of  the  analysis.  However,  unlike  what  is  the  case  for  the  semantics,  it  is 
customary  to  require  o  to  be  deterministic  and  thereby  define  a  function; 
this  will  allow  us  to  write  fp(h)  =  l2  to  mean  phii  >  l2. 

In  the  rest  of  this  section  we  shall  show  how  to  relate  the  semantics  to  the 
analysis.  We  shall  present  two  approaches  based  on  correctness  relations  and 
representation  functions,  respectively.  In  both  cases  we  shall  define  a  notion 
of  correctness  of  the  analysis  with  respect  to  the  semantics  and  we  shall  show 
that  the  two  notions  are  equivalent. 

This  is  a  mundane  approach  in  the  sense  that  it  only  applies  to  analyses 
where  properties  directly  describe  sets  of  values.  This  is  the  case  for  the 
Constant  Propagation  Analysis  of  Section  2.3,  the  Shape  Analysis  of  Section 
2.6  and  the  Control  Flow  Analysis  of  Chapter  3  but  it  is  not  the  case  for 
the  Live  Variable  Analysis  of  Section  2.1  where  properties  are  related  to 
relations  between  values.  In  the  literature,  the  terms  first-order  analyses 
versus  second-order  analyses  have  been  used  to  differentiate  between  these 
classes  of  analyses.  It  is  important  to  stress  that  the  development  of  Sections 
4.2  to  4.5  apply  equally  well  to  both  classes. 

We  begin  by  showing  how  the  development  of  Chapters  2  and  3  can  be 
rephrased  in  the  style  of  (4.1)  and  (4.2). 

Example  4.1  Consider  the  WHILE  language  of  Chapter  2.  Recall  that 
the  semantics  is  a  Structural  Operational  Semantics  with  transitions  of  the 
forms  (S,  a)  —I  {S', a')  and  (S,o)  -4  o',  where  S  and  S'  are  statements  of 
Stmt  and  o  and  o'  are  states  of  State  =  Var  -4  Z.  With  5*  being  the 
program  of  interest  we  shall  now  write 

S*  H  <Ji  o2 


for  the  reflexive  transitive  closure  of  the  transition  relation,  i.e.  for: 


(5*,cti)  -4*  o2 


Note  that  the  set  V  of  values  is  the  set  State. 

We  shall  now  consider  the  Constant  Propagation  Analysis  of  Section  2.3. 
Recall  that  the  analysis  of  S*  gives  rise  to  a  set  of  equations  CP=  formulated 
in  terms  of  an  instance  of  a  Monotone  Framework:  the  properties  L  of  interest 
are  given  by  Statecp  =  (Var*  -4  ZT)x,  E  is  {init(5*)},  F  is  flow(5*),  and  l 
is  Ax.T.  Further  recall  that  a  solution  to  the  equations  is  a  pair  (CP0,  CP,) 
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of  mappings  CP0  :  Lab*  -4  Statecp  and  CP.  :  Lab*  -4  Statecp  satisfying 
the  equations.  Given  a  solution  (CP0,CP.)  to  CP=  we  take 

5*  t-  <?i  >  ?2 


to  mean  that: 


L  =  a1  A  52  =  U{CP.(0  1 1  6  finaf(S*)} 

Thus  for  a  program  5*  with  isolated  entries,  d\  is  the  abstract  state  associated 
with  the  entry  point  of  5*,  and  a-i  is  the  abstract  state  associated  with  the 
exit  points;  we  use  the  least  upper  bound  operation  (U)  on  the  complete 
lattice  Statecp  to  combine  the  contributions  from  the  (possibly  several)  exit 
points  of  5*.  ■ 


Example  4.2  Consider  the  Fun  language  of  Chapter  3.  Recall  that  the 
semantics  is  given  by  a  Structural  Operational  Semantics  with  transitions  of 
the  form  p  1-  ie  -4  ie'  where  p  is  an  environment  of  Env  =  Var  -4fin  Val  and 
ie  and  ie'  are  intermediate  expressions  of  IExp.  Let  now  e*  be  the  closed 
expression  of  interest.  We  shall  write 


e*  b  v\  V2 

to  mean  that  e*  when  given  the  argument  v\  will  evaluate  to  the  value  u2, 
i.e.  that 

[  ]  b  (e*  uf1)*2  v'2 

where  i\  and  l-i  are  fresh  labels.  Note  that  the  set  V  of  values  now  is  the  set 
Val. 

We  shall  next  consider  the  pure  Control  Flow  Analysis^  of  Section  3.1.  Recall 
that  the  result  of  analysing  the  expression  e*  is  a  pair  (C,  p)  satisfying  (C,  p)  |= 
e*  as  defined  in  Table  3.1.  Here  C  is  an  element  of  Cache  =  Lab*  -4  Val 
and  p  is  an  element  of  Env  =  Var*  -4  Val  where  Val  =  ^(Term*).  For 
this  analysis  we  shall  take  the  properties  L  of  interest  to  be  pairs  (p,  v)  of 
Env  x  Val  and  assume  that  (C,  p)  }=  (e*  c*1  )<2  for  some  constant  c.  Then 
we  define 

e*  b  (pi,vi)  >  (p2,F2) 

to  mean  that  when  e*  is  given  an  argument  with  property  (pi,Fi)  then  the 
result  of  the  application  will  have  property  {(>2,02): 

C(/i)  =  »i  A  C(/2)  =  ^2  A  pi  =  p2  =  p 

Note  that  the  “dummy”  constant  c  used  as  an  argument  to  e*  is  used  as  a 
place  holder  for  all  potential  arguments  being  described  by  Fi;  for  this  idea 
to  work  it  is  important  that  the  analysis  of  c  puts  no  constraints  on  (C,  p)  as 
in  indeed  the  case  for  the  specification  in  Table  3.1.  ■ 
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4.1.1  Correctness  Relations 

Every  program  analysis  should  be  correct  with  respect  to  the  semantics.  For  a 
class  of  (so-called  first-order)  program  analyses  this  is  established  by  directly 
relating  properties  to  values  using  a  correctness  relation : 

R:V  x  L  — ►  {true, false} 

The  intention  is  that  v  R  l  formalises  our  claim  that  the  value  v  is  described 
by  the  property  l. 

Correctness  formulation.  To  be  useful  one  has  to  prove  that  the 
correctness  relation  R  is  preserved  under  computation:  if  the  relation  holds 
between  the  initial  value  and  the  initial  property  then  it  also  holds  between 
the  final  value  and  the  final  property.  This  may  be  formulated  as  the  impli¬ 
cation 

Vi  R  li  A  p  I-  t>i  V2  A  p  I-  li  >  I2  =>  V2  R  h  (4.3) 

and  is  also  expressed  by  the  following  diagram: 


p  h  Vi  t>2 

R  "  =>  R 
p  b  h  >  h 

A  relation  R  satisfying  a  condition  like  this  is  often  called  a  logical  relation 
and  the  implication  is  sometimes  written  (p  I-  •  ■)(/?-»■  R)(p  ■  >  •). 

The  theory  of  Abstract  Interpretation  comes  to  life  when  we  augment  the  set 
of  properties  L  with  a  preorder  structure  and  relate  this  to  the  correctness 
relation  R.  The  most  common  scenario  is  when  L  =  (L,  C,  U,  (1,  _L,  T)  is  a 
complete  lattice  with  partial  ordering  C  (see  Appendix  A).  We  then  impose 
the  following  relationship  between  R  and  L: 

v  Rli  A  liQh  =>  v  R  I2  (4.4) 

(VZ  €  V  C  L  :  v  R  l)  =>  v  R  ([“]£')  (4.5) 

Condition  (4.4)  says  that  the  smaller  the  property  is  with  respect  to  the 
partial  ordering,  the  better  (i.e.  more  precise)  it  is.  This  is  an  “arbitrary” 
decision  in  the  sense  that  we  could  instead  have  decided  that  the  larger  the 
property  is,  the  better  it  is,  as  is  indeed  the  case  in  much  of  the  literature  on 
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Data  Flow  Analysis;  luckily  the  principle  of  duality  from  lattice  theory  (see 
the  Concluding  Remarks)  tells  us  that  this  difference  is  only  a  cosmetic  one. 

Condition  (4.5)  says  that  there  is  always  a  best  property  for  describing  a 
value.  This  is  important  for  having  to  perform  only  one  analysis  (using  the 
best  property,  i.e.  the  greatest  lower  bound  of  the  candidates)  instead  of 
several  analyses  (one  for  each  of  the  candidates).  Recall  from  Appendix  A 
that  a  subset  Y  of  L  is  a  Moore  family  if  and  only  if  (f]T')  6  Y  for  all  subsets 
Y'  of  Y.  We  can  then  see  that  condition  (4.5)  is  equivalent  to  the  demand 
that  {/ 1  v  R  1}  is  a  Moore  family. 

Condition  (4.5)  has  two  immediate  consequences: 

v  R  T 

v  Rl\  A  v  Rh  =4>  v  R  (l\  n  1%) 

The  first  formula  says  that  T  describes  any  value  and  the  second  formula  says 
that  if  we  have  two  descriptions  of  a  value  then  their  greatest  lower  bound  is 
also  a  description  of  the  value. 

Example  4.3  Returning  to  the  Constant  Propagation  Analysis  of  Exam¬ 
ple  4.1  we  can  now  specify  the  relation 

Rcp  :  State  x  Statecp  -»  { true,  false} 

between  the  values  (i.e.  the  states)  and  the  properties  (i.e.  the  abstract 
states): 

a  Rcp  o  iff  Vx  €  FV(Sir)  :  (a(x)  =  T  V  cr(x)  =  cr{x)) 

Thus  a  may  map  some  variables  to  T  but  if  a  maps  a  variable  a:  to  an  element 
in  Z  then  this  must  also  be  the  value  of  a(x). 

Let  us  observe  that  the  conditions  (4.4)  and  (4.5)  are  fulfilled  by  the  Con¬ 
stant  Propagation  Analysis.  Recall  from  Section  2.3  that  (Statecp,  CCp)  is 
a  complete  lattice  with  the  ordering  CCp.  It  is  then  straightforward  to  verify 
that  (4.4)  and  (4.5)  do  indeed  hold.  (Also  compare  with  Exercise  2.7.)  ■ 


Example  4.4  For  the  Control  Flow  Analysis  mentioned  in  Example  4.2 
we  shall  define 


Rqfa  :  Val  x  (Env  x  Val)  -4  {true,  false} 
to  be  the  relation  V  of  Section  3.2: 


u 


v  RCfa  (p,v)  iff  v  V  (p,v) 
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Recall  that  we  have  two  kinds  of  values  v  e  Val,  constants  c  and  closures 
close  t  in  p,  and  that  V  is  given  by: 


true 

t  €.  v  A  Vx  €  dom(p)  :  p(x)  V  (p,  p{x)) 


if  v  =  c 

if  v  =  close  t  in  p 


The  correctness  condition  (4.3)  can  be  reformulated  as 


(Vi  V  (p,V] i)  [  ]  h  (e*  uf1)*2  -4*  Uj2  A  (C,p)  |=  (e*  ctl)e*  A 

C(/i)  =  »i  A  C(f2)  =  v2 )  =>  u2  V  (p,u2) 


and  it  follows  from  the  correctness  result  established  by  Theorem  3.10  in 
Section  3.2  (see  Exercise  4.3). 

Finally,  let  us  observe  that  the  Control  Flow  Analysis  also  satisfies  the  con¬ 
ditions  (4.4)  and  (4.5).  For  this  we  shall  equip  Env  x  Val  with  the  partial 
ordering  Ccfa  defined  by: 


(Pi,  Wi)  ^CFA  (P2,v2)  iff  Vi  Cv2  A  Vx:  pi(x)  C  p2(x) 

This  will  turn  Env  x  Val  into  a  complete  lattice.  By  induction  on  v  €  Val 
one  can  then  easily  prove  that  (4.4)  and  (4.5)  are  fulfilled.  ■ 


4.1.2  Representation  Functions 

An  alternative  approach  to  the  use  of  a  correctness  relation  R  :  V  x  L  -4 
{ true,  false}  between  values  and  properties  is  to  use  a  representation  function : 

p:V^L 

The  idea  is  that  P  maps  a  value  to  the  best  property  describing  it.  The 
correctness  criterion  for  the  analysis  will  then  be  formulated  as  follows: 

P(,v l)  E  Ji  A  p  H  i>!  v2  A  p  h  h  >  l2  =*■  P(v2)Cl2  (4.6) 

This  is  also  expressed  by  the  following  diagram: 

v2 

P 
m 
h 


P  h 


Vi 


0 


P  h 


m 

h 


Thus  the  idea  is  that  if  the  initial  value  Vi  is  safely  described  by  l\  then  the 
final  value  v2  will  be  safely  described  by  the  result  l2  of  the  analysis. 
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Equivalence  of  correctness  formulations.  Lemma  4.5  below 
shows  that  the  formulations  (4.3)  and  (4.6)  of  the  correctness  of  the  analysis 
are  indeed  equivalent  (when  R  and  0  are  suitably  related).  To  establish 
this  we  shall  first  show  how  to  define  a  correctness  relation  Rp  from  a  given 
representation  function  0: 

v  Rp  l  iff  0(v)  C  l 

Next  we  show  how  to  define  a  representation  function  0r  from  a  correctness 
relation  R: 

0r(v)  =  [~\{l\vRl] 


Lemma  4.5 

(i)  Given  0  :  V  -»  L,  then  the  relation  Rp  :  V  x  L  ->  {true,  false)  satisfies 
conditions  (4.4)  and  (4.5),  and  furthermore  0r0  =  0. 

(ii)  Given  R  :  V  x  L  -4  {true,  false)  satisfying  conditions  (4.4)  and  (4.5), 
then  0r  is  well-defined  and  RpR  =  R. 

Hence  the  two  formulations  (4.3)  and  (4.6)  of  correctness  axe  equivalent.  ■ 

Proof  To  prove  (i)  we  first  observe  that  condition  (4.4)  is  immediate  since  C  is 
transitive.  Condition  (4.5)  is  immediate  because  when  0(v)  is  a  lower  bound  for  L' 
we  have  0(v)  C  ^L,•  The  calculation  0n0 (v)  =  |""|{f  |  v  Rp  /}  —  I-])!  I  P(v)  E  0  = 
0(v )  then  concludes  the  proof  of  (i)>  ' 

To  prove  (ii)  we  observe  that  from  v  R  l  we  get  0r(v)  C  /  and  hence  v  Rpn  l. 
Conversely,  from  v  Rpn  l  we  get  0r{v)  C  I;  writing  U  =  {l  |  v  R  1}  it  is  clear  that 
(4.5)  gives  v  R  (f~| L')  and  this  amounts  to  v  R  (0r(v))\  we  then  get  the  desired 
result  v  R  l  by  (4.4).  ■ 

Motivated  by  these  results  we  shall  say  that  the  relation  R  is  generated  by 
the  representation  function  0  whenever  v  R  l  is  equivalent  to  0{v)  C  l.  This 
relationship  is  illustrated  in  Figure  4.1:  The  relation  R  expresses  that  v  is 
described  by  all  the  properties  above  0(v)  and  0  expresses  that  among  all 
the  properties  that  describe  v,  0{v)  is  the  best. 

Example  4.6  For  the  Constant  Propagation  Analysis  studied  in  Exam¬ 
ples  4.1  and  4.3  we  shall  define 

0zp  :  State  — >  Statecp 

as  the  injection  of  State  into  Statecp:  0cp{a)  =  Xx.a(x).  It  is  straightfor¬ 
ward  to  verify  that  Rqp  is  generated  by  0cp,  i.e. 

a  Rqp  d  0cp {&)  Ecp  & 

using  the  definition  of  the  ordering  Cep  on  Statecp.  ■ 
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Figure  4.1:  Correctness  relation  R  generated  by  representation  function  /3. 


Example  4.7  For  the  Control  Flow  Analysis  studied  in  Examples  4.2  and 
4.4  we  shall  define 

/3c fa  :  Val  — >  Env  x  Val 
inductively  on  the  structure  of  values  v  E  Val: 

a  ,  \  _  f  (Ax.0, 0J  if  v  =  c 

Pcfa{v)  -  |  {*})  if  v  =  close  *  in  p 

The  first  clause  reflects  that  we  do  not  collect  constants  in  a  pure  0-CFA 
analysis.  In  the  second  clause  we  only  have  one  closure  so  the  abstract  value 
will  be  a  singleton  set  and  we  construct  the  associated  “minimal”  abstract 
environment  by  extending  /?cfa  to  operate  on  environments.  To  do  that 
we  shall  “merge”  all  the  abstract  environments  occurring  in  U{/^cfa(p(x))  | 
x  E  Var*};  this  reflects  that  the  0-CFA  analysis  uses  one  global  abstract 
environment  to  describe  all  the  possible  local  environments  of  the  semantics. 
So  we  define  :  Env  — »  Env  by: 

Pcfa (p)(*)  =  [J{Py(x)\PcFA(p(y))  =  {Py,Vy)  and  yEdom(p)} 

y  f  {vx}  if  x  E  dom(p)  and  /3Cfa (p(x))  =  (px,%) 

\  0  otherwise 

To  show  that  I?cfa  is  generated  by  Pcfa  we  have  to  show  that: 

v  Rcfa  (p,v)  ^  Pcfa(v)  Ccfa  (p,v) 

This  follows  by  induction  on  v  E  Val  and  we  leave  the  details  to  Exercise 
4.4.  ■ 
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4.1.3  A  Modest  Generalisation 

We  shall  conclude  by  performing  a  modest  generalisation  of  the  development 
performed  so  far.  A  program  p  specifies  how  one  value  Vi  is  transformed  into 
another  value  u2 : 

p  h  Vi  v2 

Here  v\  £  Vi  and  v2  £  V2  and  we  shall  subsequently  refrain  from  imposing 
the  condition  that  V\  =  V2]  thus  we  shall  allow  the  programs  to  have  different 
“argument”  and  “result”  types  -  this  will  e.g.  be  the  case  for  most  functional 
programs.  The  analysis  of  p  specifies  how  a  property  li  is  transformed  into 
a  property  12: 

p  f-  h  >  I2 

Here  li  £  Li  and  I2  £  L2  and  again  we  shall  refrain  from  imposing  the 
restriction  that  Li  =  L2.  As  previously  argued  it  is  natural  to  demand  that 
p  h  1 1  >  h  specifies  a  function 

fp  ■  ->•  L2 

given  by  fp(li)  =  l2  iff  p  h  h  >  12- 

Turning  to  the  correctness  conditions  we  shall  now  assume  that  we  have  two 
correctness  relations,  one  for  Vi  and  L\  and  one  for  V2  and  L2: 

Ri  :  Vi  x  L\  — >  {true,  false}  generated  by  p\  :  V}  -4  L\ 

R2  :  V2  x  L2  -4  {true,  false}  generated  by  /?2  :  V2  -4  L2 

Correctness  of  fp  now  amounts  to 

«i  Ri  li  A  p  h  vi  v2  =>  v2  R2  fp(h) 

for  all  V\  £  Vi,  V2  £  V2  and  l\  £  Li-  Using  the  concept  of  logical  relations 
(briefly  mentioned  above)  this  can  be  written  as: 

(p  b  •  •)  (jRi  -»  R2)  fp 

To  be  precise,  (Ri  -»  R2)  f  means  that: 

Vui,u2,li  :vi-^*V2  A  ui  Ri  h  =>  v2  R2  f{h) 

Higher-order  formulation.  We  can  now  ask  whether  the  relation 
Ri  -»  f?2  defined  above  is  a  correctness  relation.  Lemma  4.8  below  shows 
that  this  is  indeed  the  case  and  furthermore  that  we  can  find  a  representation 
function  P  such  that  R\  -#  R2  is  generated  by  (3.  The  representation  function 
j3  can  be  defined  from  the  representation  functions  Pi  and  (32  and  it  will  be 
denoted  Pi  -»  p2- 

{Pi  =  Mi- |_|{^2(v2)  |  Pi(vi)  C  li  A  Vi  V2} 


f  i 
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Lemma  4.8  If  R,  is  a  correctness  relation  for  V)  and  Li  that  is  generated 
by  the  representation  function  fa  :  Vi  -¥  Li  (for  i  =  1,2)  then  R\  -#•  R2 
is  a  correctness  relation  and  it  is  generated  by  the  representation  function 
fa  -*  fa.  u 


Proof  We  shall  prove  ( Ri  -*  R2)  f  &  (fa  -*  fa)(^*)  C  /.  We  calculate: 


(fa-*  fa  )H)E/ 

4* 

4* 

44- 


Vb  :  (J{/32(u2)  1  fa(vi)  Ch  AVI  v2}  c  f(h) 
Vli,ui,u2  :  (fa(vi)  C  h  A  v\  v2  =4>  /?2(v2)  C  /(Zi)) 
VZi,t)i,t;2  :  (ui  fii  li  A t)i  ^  t)2  =>  t)2  fZ2  /(Zi)) 

(i2i  — #■  fZ2)  / 


Note  that  it  now  follows  (from  Lemma  4.5)  that  if  each  Ri  satisfies  conditions  (4.4) 
and  (4.5)  then  so  does  Ri  -*  R2.  m 


Example  4.9  Consider  the  program  plus  with  the  semantics  given  by 

plus  I-  (zi,  z2)  Zi  +  Z2 

where  z\  z2  £  Z.  A  very  precise  analysis  might  use  the  complete  lattices 
(V(Z),  C)  and  (V(Z  x  Z),  C)  as  follows: 

fpius(ZZ)  =  [zi  +  z2  |  (^1,^2)  £  ZZ) 

where  ZZ  CZxZ.  Consider  now  the  correctness  relations  Rz  and  i?zxz 
generated  by  the  representation  functions: 

Pz(z)  =  {z} 
faxz(z\  ,z2)  =  {(zi,z2)} 

The  correctness  of  the  analysis  of  plus  can  now  be  expressed  by 
Vzi,z2,z,ZZ:  plus  fr  (zi,z2)  z  A  (zi,z2)  RZxz  ZZ  =>  z  Rz  fP\us(ZZ ) 
or  more  succinctly 

(plus  I - -  •)  (RzxZ  ~*  Rz)  /plus 

The  representation  function  faxz  fa  satisfies 

(faxz  ~*  fa )(p  I - *  •)  =  A ZZ.{z  |  ( zi,z2 )  €  ZZ  A  p  b  (zi,z2)  z} 

so  the  correctness  can  also  be  expressed  as  (faxz  -*  /?z)(plus  H  •  •)  C 

/plus-  ■ 

The  above  example  illustrates  how  the  abstract  concepts  can  give  a  more 
succinct  formulation  of  the  correctness  of  the  analysis.  In  the  following  we 
shall  see  several  cases  where  we  move  freely  between  what  we  may  call  a 
“concrete”  formulation  of  a  property  and  an  “abstract”  formulation  of  the 
same  property.  And  we  shall  see  that  the  latter  often  will  allow  us  to  reuse 
general  results  so  that  we  do  not  have  to  redevelop  parts  of  the  theory  for 
each  application  considered. 
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[-00,00] 


Figure  4.2:  The  complete  lattice  Interval  =  (Interval,  C). 


4.2  Approximation  of  Fixed  Points 

It  should  be  clear  by  now  that  complete  lattices  play  a  crucial  role  in  program 
analysis  and  in  the  remainder  of  this  chapter  we  shall  tacitly  assume  that 
property  spaces  such  as  L  and  M  are  indeed  complete  lattices.  We  refer  to 
Appendix  A  for  the  basic  notions  of  complete  lattices  and  monotone  func¬ 
tions.  Here  we  present  an  interesting  complete  lattice  that  forms  the  basis  of 
many  analyses  over  the  integers. 

Example  4.10  We  shall  now  present  a  complete  lattice  that  may  be  used 
for  Array  Bound  Analysis ,  i.e.  for  determining  if  an  array  index  is  always 
within  the  bounds  of  the  array  -  if  this  is  the  case  then  a  number  of  run-time 
checks  can  be  eliminated. 

The  lattice  (Interval,  Q  of  intervals  over  Z  may  be  described  as  follows. 
The  elements  are 

Interval  =  {X}  U  {[21,22]  |  21  <  22,2i  e  Z  U  {-oo},22  e  Z  U  {00}} 

where  the  ordering  <  on  Z  is  extended  to  an  ordering  on  Z'  =  Z  U  {-00, 00} 
by  setting  —00  <  z,  z  <  00,  and  -00  <  00  (for  all  z  €  Z).  Intuitively,  ± 
denotes  the  empty  interval  and  [21,22]  is  the  interval  from  21  to  22  including 
the  end  points  if  they  are  in  Z.  We  shall  use  int  to  range  over  elements  of 

Interval. 
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The  partial  ordering  C  on  Interval  is  depicted  in  Figure  4.2;  the  idea  is  that 
inti  C  into,  corresponds  to  {z  |  z  is  in  inti}  C  {z  \  z  is  in  int 2}  where  the 
meaning  of  “is  in”  should  be  immediate.  To  give  a  succinct  definition  of  the 
partial  ordering  we  define  the  infimum  and  supremum  operations  on  intervals 
as  follows: 


.  f  00  if  int  =  -L 

in  (tn  )  ~  |  Zl  if  int  =  [zx ,  z2] 

,,  A  f  -00  if  int  =  ± 

sup(m)  -  |  z%  if  int  =  [21 ,  z2] 

This  allows  us  to  define: 

inti  C  inta  iff  inf(inf2)  <  inf(inti)  A  sup(infi)  <  sup(int2) 

We  claim  that  (Interval,  C)  is  indeed  a  complete  lattice.  We  shall  prove  this 
by  showing  that  each  subset  of  Interval  has  a  least  upper  bound  and  then 
refer  to  Lemma  A.2  of  Appendix  A  to  get  that  (Interval,  C)  is  a  complete 
lattice.  So  let  Y  be  a  subset  of  Interval.  The  idea  is  that  each  interval  int 
of  Y  should  be  “contained  in”  the  interval  jj  Y  defined  by: 

(  1  if  Y  C  {X} 

|Jy  =  <  [  inf '{inf( int)  |  inte  Z}  ,  sup'{sup(int)  |  int  €  T}  ] 

{  otherwise 

where  inf'  and  sup'  are  the  infimum  and  supremum  operators  on  Z'  corre¬ 
sponding  to  the  ordering  <  on  Z';  they  are  given  by  inf '(0)  =  00,  inf  '(Z)  —  z' 
if  z'  6  Z  is  the  least  element  of  Z,  and  inf'(Z)  =  -00  otherwise;  and  simi¬ 
larly  sup'(0)  =  -00,  sup'(Z)  =  z’  if  z’  G  Z  is  the  greatest  element  of  Z,  and 
sup'(Z)  =  00  otherwise.  It  is  now  straightforward  to  show  that  [J  Y  is  indeed 
the  least  upper  bound  of  Y.  ■ 

Given  a  complete  lattice  L  =  (L,  C,  U,  n,  _L,  T)  the  effect  of  a  program,  p,  in 
transforming  one  property,  Zj,  into  another,  l2,  i.e.  p  h  lx  l>  Z2,  is  normally 
given  by  an  equation 

f(h)  =  h 

for  a  monotone  function  f  :  L  -¥  L  dependent  on  the  program  p.  Note 
that  the  demand  that  /  is  monotone  is  very  natural  for  program  analysis;  it 
merely  says  that  if  l[  describes  at  least  the  values  that  lx  does  then  also  f(l[) 
describes  at  least  the  values  that  f(lx)  does. 

For  recursive  or  iterative  program  constructs  we  ideally  want  to  obtain  the 
least  fixed  point,  lfp(f),  as  the  result  of  a  finite  iterative  process.  However, 
the  iterative  sequence  (/n( J_))n  need  not  eventually  stabilise  nor  need  its 
least  upper  bound  necessarily  equal  lfp(f).  This  might  suggest  considering 
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the  iterative  sequence  (/n(T))n  and  even  when  it  does  not  eventually  stabilise 
we  can  always  terminate  the  iteration  at  an  arbitrary  point  in  time.  While 
this  is  safe  (thanks  to  condition  (4.4)  of  Section  4.1)  it  turns  out  to  be  grossly 
imprecise  in  practice. 

Fixed  points.  We  shall  begin  by  recalling  some  of  the  properties  of  fixed 
points  of  monotone  functions  over  complete  lattices;  we  refer  to  Appendix 
A  for  the  details  of  this  development.  So  consider  a  monotone  function  /  : 
L  -¥  L  on  a  complete  lattice  L  =  ( L ,  C,  LI,  n,  A,  T).  A  fixed  point  of  /  is  an 
element  l  €  L  such  that  /(/)  =  l  and  we  write 

Fix(f)  =  {l\f(l)  =  l} 

for  the  set  of  fixed  points.  The  function  /  is  reductive  at  l  if  and  only  if 
f(l)  C  l  and  we  write 

Red(f)  =  {l  |  f(l)  C 1} 

for  the  set  of  elements  upon  which  /  is  reductive;  we  shall  say  that  /  itself 
is  reductive  if  Red(f)  —  L.  Similarly,  the  function  /  is  extensive  at  l  if  and 
only  if  f(l)  □  l  and  we  write 

Ext(f)  =  {i  i  m  □  i} 

for  the  set  of  elements  upon  which  /  is  extensive;  we  shall  say  that  /  itself  is 
extensive  if  Ext(f)  =  L. 

Since  L  is  a  complete  lattice  it  is  always  the  case  that  the  set  Fix(f)  will  have 
a  greatest  lower  bound  in  L  and  we  denote  it  by  Ifp(f);  this  is  actually  the 
least  fixed  point  of  /  because  Tarski’s  Theorem  (Proposition  A. 10)  ensures 
that: 

lfp(f)  =  O'*/)  =  f~>ed(/)  €  Fi*(/)  C  Red(f) 

Similarly,  the  set  Fix(f)  will  have  a  least  upper  bound  in  L  and  we  denote 
it  by  gfp(f);  this  is  actually  the  greatest  fixed  point  of  /  because  Tarski’s 
Theorem  ensures  that 

gfp(f)  =  U  Fix(f)  =  (jExt(/)  e  Fix(f)  C  Ext{f) 

In  Denotational  Semantics  it  is  customary  to  iterate  to  the  least  fixed  point  by 
taking  the  least  upper  bound  of  the  sequence  (/"(!))„.  However,  we  have  not 
imposed  any  continuity  requirements  on  /  (e.g.  that  f{\Jnln)  =  Un(/(^«)) 
for  all  ascending  chains  ( ln)n )  and  consequently  we  cannot  be  sure  to  actually 
reach  the  fixed  point.  In  a  similar  way  one  could  consider  the  greatest  lower 
bound  of  the  sequence  (/n(T))n.  One  can  show  that 

/"(A)  C  |_j n/n(A)  C  lfp(f)  C  gfp(f)  C  1„/"(T )  c  n T) 

as  is  illustrated  in  Figure  4.3;  indeed  all  inequalities  (i.e.  Q  can  be  strict 
(i.e.  £). 


t * 
f 
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/n(T) 
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u„n-L) 
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Figure  4.3:  Fixed  points  of  /. 


4.2.1  Widening  Operators 

Since  we  cannot  guarantee  that  the  iterative  sequence  (/n(_L))n  eventually 
stabilises  nor  that  its  least  upper  bound  necessarily  equals  lfp{f),  we  must 
consider  another  way  of  approximating  Ifp(/).  The  idea  is  now  to  replace 
it  by  a  new  sequence  (/y)„  that  is  known  to  eventually  stabilise  and  to  do 
so  with  a  value  that  is  a  safe  (upper)  approximation  of  the  least  fixed  point. 
The  construction  of  the  new  sequence  is  parameterised  on  the  operator  V, 
called  a  widening  operator,  the  precision  of  the  approximated  fixed  point  as 
well  as  the  cost  of  computing  it  depends  on  the  actual  choice  of  widening 
operator. 

Upper  bound  operators.  In  preparation  for  the  development,  an 
operator  U:LxL->Lona  complete  lattice  L  =  (L,  C)  is  called  an  upper 
bound  operator  if 

h  C  h  0  h  3  h 

for  all  l\,h  G  L,  i.e.  it  always  returns  an  element  larger  than  both  its  ar¬ 
guments.  Note  that  we  do  not  require  G  to  be  monotone,  commutative, 
associative,  nor  absorptive  (i.e.  that  l  U  l  =  l). 

Let  (in)n  be  a  sequence  of  elements  of  L  and  let  </>  :  L  x  L  ->  L  be  a  total 
function  on  L.  We  shall  now  use  <f>  to  construct  a  new  sequence  (/£)„  defined 
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by: 


In 

iLltln 


if  n  =  0 
if  n  >  0 


The  following  result  expresses  that  any  sequence  can  be  turned  into  an  as¬ 
cending  chain  by  an  upper  bound  operator: 


Fact  4.11  If  (Z„)n  is  a  sequence  and  G  is  an  upper  bound  operator  then 
(/£■)„  is  an  ascending  chain;  furthermore  l„  □  [_|{fo, h,  •  •  •  ,ln}  for  all  n.  ■ 

Proof  To  prove  that  (in)n  is  an  ascending  chain  it  is  sufficient  to  prove  that 
In  E  ln+i  for  all  n.  If  n  =  0  we  calculate  Iq  =  lo  E  to  G  li  =  1?.  For  the  inductive 
step  we  have  C  l„  G  ln+i  =  l^+i  as  required. 

To  prove  that  □  | _ |{2o> ii> •  •  •  ,ln}  we  first  observe  that  it  holds  trivially  for 

n  =  0.  For  the  inductive  step  we  have  i^+i  =  1%  ill  ln+i  □  (J{fo,  h,  ■  •  • ,  ln}uln+i  = 
U(/o,  h,  -  ,ln,ln+ 1}  and  the  result  follows.  ■ 


Example  4.12  Consider  the  complete  lattice  (Interval,  Q  of  Figure  4.2 
and  let  int  be  an  arbitrary  but  fixed  element  of  Interval.  Consider  the 
following  operator  G,nt  defined  on  Interval: 

-int  ■  .  f  inti  U  inh  if  inti  E  int  V  inti  E  inti 
mtiU  =  |  [.oo^j  otherwise 

Note  that  the  operation  is  not  Symmetric:  for  int  =  [0,2]  we  e.g.  have 
[l,2]G*nt[2,3]  =  [1,3]  whereas  [2,3]U,n‘[l,2]  =  [-00,00]. 

It  is  immediate  that  U,nt  is  an  upper  bound  operator.  Consider  now  the 
sequence: 

[0,0],  [1, 1],  [2,2],  [3,3],  [4,4],  [5,5],  •  •  • 

If  int  =  [0, 00],  then  the  upper  bound  operator  will  transform  the  above 
sequence  into  the  ascending  chain: 

[0, 0],  [0,1],  [0,2],  [0,3],  [0,4],  [0,5],- 

However,  if  int=  [0,2],  then  we  will  get  the  following  ascending  chain 

[0, 0],  [0, 1],  [0, 2],  [0, 3],  [-00, 00],  [-00, 00],  •  •  • 

which  eventually  stabilises.  ■ 

Widening  operators.  We  can  now  introduce  a  special  class  of  upper 
bound  operators  that  will  help  us  to  approximate  the  least  fixed  points:  An 
operator  V:LxL— is  a  widening  operator  if  and  only  if: 

•  it  is  an  upper  bound  operator,  and 
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Figure  4.4:  The  widening  operator  V  applied  to  /. 


•  for  all  ascending  chains  (Zn)rt-the  ascending  chain  (Zj)„  eventually  sta¬ 
bilises. 


Note  that  it  follows  from  Fact  4.11  that  (l^)n  is  indeed  an  ascending  chain. 

The  idea  is  as  follows:  Given  a  monotone  function  /  :  L  ->  L  on  a  com¬ 
plete  lattice  L  and  given  a  widening  operator  V  on  L,  we  shall  calculate  the 
sequence  (/y)„  defined  by 


r  ± 


/r1 

/r1  v  /(/r1) 


if  n  =  0 

if  n  >  o  a  /(/r1)  e  /r1 

otherwise 


As  in  Fact  4.11  it  follows  that  this  is  an  ascending  chain  and  Proposition  4.13 
below  will  ensure  that  this  sequence  eventually  stabilises.  From  Fact  4.14 
below  we  shall  see  that  this  means  that  we  will  eventually  have  /(/y )  C  /y 
for  some  value  of  m  (corresponding  to  the  second  clause  in  the  definition 
of  /y ).  This  means  that  /  is  reductive  at  and  from  Tarski’s  Theorem 
(Proposition  A.  10)  we  then  know  that  /y  □  lfp(f)  must  be  the  case;  hence 
we  take 

fiPv(/) =  fv 

as  the  desired  safe  approximation  of  lfp(f).  This  is  illustrated  in  Figure  4.4. 
We  shall  now  establish  the  necessary  results. 
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Proposition  4.13 

If  V  is  a  widening  operator  then  the  ascending  chain  (/$)„  even¬ 
tually  stabilises. 


In  preparation  for  the  proof  of  Proposition  4.13  we  shall  first  show  the  fol¬ 
lowing  technical  result: 

Fact  4.14  If  V  is  a  widening  operator  then: 

(i)  the  sequence  (/y)„  is  an  ascending  chain; 

(ii)  if  /(/y  )  E  /v  for  some  m  then  the  sequence  (/y)„  eventually  stabilises 
and  furthermore  Vn  >  m  :  /y  =  /y  and  jJB  /y  =  /y  ; 

(iii)  if  (/y)n  eventually  stabilises  then  there  exists  an  m  such  that  /(/y )  tl 
/y ;  and 

(iv)  if  (/y)„  eventually  stabilises  then  [_|n  /y  □  lfp(f). 

These  claims  also  hold  if  V  is  just  an  upper  bound  operator.  ■ 

Proof  The  proof  of  (i)  is  analogous  to  that  of  Fact  4.11  so  we  omit  the  details. 

To  prove  (ii)  we  assume  that  /(/y  ),’C  /y  for  some  m.  By  induction  on  n  >  m 
we  prove  that  /y  =  /y  :  for  n  =  m  4- 1  it  follows  from  the  assumption  and  for  the 
inductive  step  we  note  that  /(/y)  E  /y  will  be  the  case  so  /y+1  =  /y.  Thus  (/£)„ 
eventually  stabilises  and  it  follows  that  |Jn  /y  =  /y  . 

To  prove  (iii)  we  assume  that  (/y)„  eventually  stabilises.  This  means  that  there 
exists  m  such  that  Vn  >  m  :  /y  =  /y  .  By  way  of  contradiction  assume  that 
/(/v  )  E  /v  does  not  hold;  then  /£  =  f™+1  =  V  /(/y)  3  /(/^)  and  we  have 
the  desired  contradiction. 

To  prove  (iv)  we  observe  that  (ii)  and  (iii)  give  |_|n  /y  =  /y  for  some  rn  where 
/(/y )  C  /y .  Hence  /y  €  Red(f)  and  by  Tarski’s  Theorem  (Proposition  A.  10) 
this  shows  /y  □  i/p(/).  ■ 

We  now  turn  to  the  proof  of  Proposition  4.13: 

Proof  By  way  of  contradiction  we  shall  assume  that  the  ascending  chain  (/y)n 
never  stabilises;  i.e.: 

Vn0  :  3n  >  no  :  /y  /  fv° 

It  follows  that  /(/y-1)  E  /y_1  never  holds  for  any  n  >  0;  because  if  it  did, 
then  Fact  4.14  gives  that  (/y)n  eventually  stabilises  and  our  hypothesis  would  be 
contradicted.  This  means  that  the  definition  of  (/y)n  specialises  to: 

n  _  /  -L  if  n  =  0 

\  /y_1  V  /(/y-1)  otherwise 
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Now  define  the  sequence  (Z„)n  by 

.  _  f  1  ifn  =  0 

n~\  /(/r‘)  if">0 

and  note  that  ( ln)n  is  an  ascending  chain  because  (/$)„  is  an  ascending  chain  (Fact 
4.14)  and  /  is  monotone.  We  shall  now  prove  that 

Vn  :  £  =  /$ 

by  induction  on  n:  for  n  =  0  it  is  immediate  and  for  n  >  0  we  have  =  l%-  j  V  /„  = 
/y-1  V  /(/y_1)  =  /v-  Since  (/„)„  is  an  ascending  chain  and  V  is  a  widening  op¬ 
erator  it  follows  that  the  sequence  (l„  )„  eventually  stabilises,  i.e.  (/y)„  eventually 
stabilises.  This  provides  the  desired  contradiction  and  proves  the  result.  ■ 


Example  4.15  Consider  the  complete  lattice  (Interval,  C)  of  Figure  4.2. 
Let  K  be  a  finite  set  of  integers,  e.g.  the  set  of  integers  explicitly  mentioned 
in  a  given  program.  We  shall  now  define  a  widening  operator  Vr-  based  on 
K.  The  idea  is  that  [z\ ,  z2]  Vr-  [23 , 24]  is  something  like 

[  LB(zi,z3)  ,  UB(z2, 24)  ] 

where  LB(zi,Z3)  €  {zi}  U  K  U  {-00}  is  the  best  possible  lower  bound  and 
UB(z2,  Z4)  G  {z2}  U  K  U  {00}  is  the  best  possible  upper  bound.  In  this  way 
a  change  in  any  of  the  bounds  of  the  interval  [zi ,  z2]  can  only  take  place  in  a 
finite  number  of  steps  (corresponding  to  the  elements  of  K). 

For  the  precise  definition  we  let  Zj  G  Z'  =  ZU  {—00, 00}  and  write: 


f  Z1 

if  zi  <  23 

LBk{zi,z3)  =  <  k 

if  z3  <  zi  A  k  =  max{fc  G  K  |  k  <  z3} 

[  -00 

if  23  <  zi  A  V&  G  K  :  z3  <  k 

f  *2 

if  Z4  <  z2 

UB/c (22,24)  =  <  k 

if  Z2  <  24  A  k  =  min{A;  G  K  |  24  <  k} 

[  00 

if  z2  <  24  A  VA:  G  K  :  k  <  24 

We  can  now  define  V  =  Vr-  by: 

{X  if  inti  =  inh  =  X 

[  LBjR'(inf(tnti),inf(int2)),UBic(sup(mti),sup(mt2))  ] 
otherwise 


As  an  example  consider  the  ascending  chain  (mtn)„: 

[0, 1],  [0, 2],  [0, 3],  [0, 4],  [0, 5],  [0, 6],  [0, 7],-  •  • 
and  assume  that  K  =  {3,5}.  Then  (int^)n  will  be  the  chain 
[0, 1],  [0, 3],  [0, 3],  [0, 5],  (0, 5],  [0, 00],  [0, 00],  - 
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It  is  straightforward  to  show  that  V  is  indeed  an  upper  bound  operator.  To 
show  that  it  is  a  widening  operator  we  consider  an  ascending  chain  ( intn)n 
and  must  show  that  the  ascending  chain  (mt^)n  eventually  stabilises.  By  way 
of  contradiction  suppose  that  (in%)n  does  not  eventually  stabilise.  Then  at 
least  one  of  the  following  properties  will  hold: 

(Vn  :  inf(mt^)  >  -oo)  A  inf(| _ |  „ int% )  =  -oo 

(Vn  :  sup(int^)  <  oo)  A  sup(|_J  =  oo 

Without  loss  of  generality  we  can  assume  that  the  second  property  holds. 
Hence  there  must  exist  an  infinite  sequence  n\  <  m  <  •  •  •  such  that 

Vi :  oo  >  sup(m£.+1)  >  sup(m£.) 

and  by  finiteness  of  K  there  must  be  some  j  such  that 

Vi  >  j  :  oo  >  sup(ini^.+1)  >  sup(inf)f.)  >  max(.?L) 

where  for  the  purpose  of  this  definition  we  set  max(0)  =  — oo.  Since  we  also 
have 

*«£,+ 1  =  *«£,  V  intn]+l 

it  must  be  the  case  that  sup(intnj+i)  >  sup (ini^  )  as  otherwise  sup(mt^.+1) 
=  sup(int^).  But  then  the  construction  yields 

sup(in£.+1)  =  oo 

and  we  have  the  desired  contradiction.  This  shows  that  V  is  a  widening 
operator  on  the  complete  lattice  of  intervals.  ■ 


4.2.2  Narrowing  Operators 

Using  the  technique  of  widening  we  managed  to  arrive  at  an  upper  approx¬ 
imation  /y  of  the  least  fixed  point  of  /.  However,  we  have  /(/y )  E  /v 
so  /  is  reductive  at  /y  and  this  immediately  suggests  a  way  of  improving 
the  approximation  by  considering  the  iterative  sequence  (/"(/y  ))n-  Since 
/y  6  Red(f)  this  will  be  a  descending  chain  with  /n(/y )  £  Red(f)  and 
hence  /n(/y )  3  hjp (/)  for  all  n.  Once  again  we  have  no  reason  to  believe 
that  this  descending  chain  eventually  stabilises  although  it  is  of  course  safe 
to  stop  at  an  arbitrary  point.  This  scenario  is  not  quite  the  one  we  saw  above 
but  inspired  by  the  notion  of  widening  we  can  define  the  notion  of  narrowing 
that  encapsulates  a  termination  criterion.  This  development  can  safely  be 
omitted  on  a  first  reading. 

An  operator  A  :  L  x  L  — >  L  is  a  narrowing  operator  if: 
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[/]°A=/V* 

[/3  k 

[/]  a'-1 

im'  =[/]  a'+1  =  --- 


Figure  4.5:  The  narrowing  operator  A  applied  to  /. 


•  h  E  h  =>  h  E  (h  A  /2)  f°r  all  h,h  €  L,  and 

•  for  all  descending  chains  ( ln)n  the  sequence  (l£)n  eventually  stabilises. 

Note  that  we  do  not  require  A  to  be  monotone,  commutative,  associative  or 
absorptive.  One  can  show  that  (l„)n  is  a  descending  chain  when  (/„)„  is  a 
descending  chain  (Exercise  4.10). 

The  idea  is  as  follows:  For  satisfying  /(/v )  C  /y*,  i.e.  i/pv  (/)  =  /v  >  we 
now  construct  the  sequence  ([/]£) n  by 


f$  if  n  =  0 

mr1  a  /(mr1)  ^  ^  >  o 


Lemma  4.16  below  guarantees  that  this  is  a  descending  chain  where  all  ele¬ 
ments  satisfy  lfp(f)  C  [/]£.  Proposition  4.17  below  tells  us  that  this  chain 
eventually  stabilises  so  [/]£  =  [/])£  +1  for  some  value  m! .  We  shall  therefore 
take 

ifPv(f)  =  I/3S' 

as  the  desired  approximation  of  lfp(f)-  The  complete  development  is  illus¬ 
trated  in  Figures  4.4  and  4.5.  We  shall  now  establish  the  required  results. 
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Lemma  4.16  If  A  is  a  narrowing  operator  and  /(/y )  3  /y  then  ([/]£)„ 
is  a  descending  chain  in  Red(f)  and 


[/]  1  3  r(/v )  3 


for  all  n. 


Proof  By  induction  on  n  we  prove: 

/n+1(/v)  E  /([/] a)  E  Ma+1  E  [f]l  (4.7) 

For  the  basis  (n  =  0)  it  is  immediate  that 

/n+1(/v  )  E  /([/]a)  E  [/]a 

using  that  /(/y )  E  /y .  By  construction  of  [/]^+1  we  then  get 

/([/] A)  E  [/]nA+1  E  [/] A 

and  together  these  two  results  establish  the  basis  of  the  induction  proof. 

For  the  inductive  step  we  may  apply  /  to  the  induction  hypothesis  (4.7)  and  get 

r+2(/v )  E  f\[f]!)  E  f([f}l+1)  E  /([/]£) 

since  /  is  assumed  to  be  monotone.  Using  the  induction  hypothesis  we  also  have 
/([/] a)  E  lf]T  so  we  obtain: 

r+2(/v)E-/([/]l+1)E[/lA+1 

By  construction  of  [/]^+2  we  get 

/(Ma+1)  e  [/1a+2  e  [/]a+1 

and  together  these  two  results  complete  the  proof  of  (4.7). 

From  (4.7)  it  now  follows  that  ([/]£)„  is  a  descending  chain  in  Red(f).  It  also 
follows  that  /"(/y )  E  [/]a  holds  for  n  >  0  and  it  clearly  also  holds  for  n  —  0. 
From  the  assumption  /(/y )  E  /v  it  is  immediate  that  /(/n(/v  ))  E  /"(/y  )  for 
n  >  0  and  hence  /n(/y )  €  Red(f).  But  then  /n(/y  )  3  hp(/)-  This  completes  the 
proof.  ■ 


Proposition  4.17 

If  A  is  a  narrowing  operator  and  /(/y )  3  /v  t^ien  t^ie  descending 
chain  ([/]^)n  eventually  stabilises. 
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and  note  that  this  defines  a  descending  chain  because  ([/]£)«  is  a  descending  chain 
and  because  /([/]a)  Q  fv  ■  Therefore  the  sequence  (i„  )n  eventually  stabilises.  We 
now  prove  by  induction  on  n  that: 

In  =  [f]l 

The  basis  (n  =  0)  is  immediate.  For  the  inductive  step  we  calculate  i£+1  = 
In  A  ln+ 1  =  [/]1  A/([/]a)  =  [flT1  ■  It  thus  follows  that  ([/]£.)„  eventually 
stabilises.  ■ 

It  is  important  to  stress  that  narrowing  operators  are  not  the  dual  concept 
of  widening  operators.  In  particular,  the  sequence  (/£)„  may  step  outside 
Ext(f)  in  order  to  end  in  Red(f),  whereas  the  sequence  ([/]£)»!  stays  in 
Red(f)  all  the  time. 

Example  4.18  Consider  the  complete  lattice  (Interval,  C)  of  Figure  4.2. 
Basically  there  are  two  kinds  of  infinite  descending  chains  in  Interval:  those 
with  elements  of  the  form  [-oo,  z)  and  those  with  elements  of  the  form  [z,  oo] 
where  z  €  Z.  Consider  an  infinite  sequence  of  the  latter  form;  it  will  have 
elements 

[^■li  00]i  [^2>  [Z3>  Oo],  •  •  • 

where  Z\  <  z-i  <  Z3  <  •  •  •.  The  idea  is  now  to  define  a  narrowing  operator 
An  that  will  force  the  sequence  to  stabilise  when  Zi>  N  for  some  fixed  non¬ 
negative  integer  N.  Similarly,  for  a  descending  chain  with  elements  of  the 
form  [—00,  Zi]  the  narrowing  operator  will  force  it  to  stabilise  when  Z{  <  —N. 

Formally,  we  shall  define  A  =  Aw  by 


inti  A  inl^ 


-  { L 


if  inti  =1  V  inti  —  -L 
Zi ]  otherwise 


where 


_  f  inf^nfx)  if  AT  <  inf( infe)  A  sup(mt2)  =  00 
Zl  \  inf (171*2)  otherwise 

_  f  sup(tn*1)  if  inf(  171*2)  =  ~oo  A  sup(m*2)  <  —N 
Z 2  \  sup(i7i*2)  otherwise 

So  consider  e.g.  the  infinite  descending  chain  (jn,  oc])n 

[0, 00],  [1, 00],  [2, 00],  [3, 00],  [4, 00],  [5, 00],  •  •  • 

and  assume  that  N  =  3.  Then  the  operator  will  give  the  sequence  ([n,  oo]A)„: 

[0, 00],  [1, 00],  [2, 00],  [3, 00],  [3, 00],  [3, 00],  •  •  • 

Let  us  show  that  A  is  indeed  a  narrowing  operator.  It  is  immediate  to  verify 
that 

i7i*2  E  i7i*i  implies  inti  C  inti  A  m*2  C  inti 
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by  cases  on  whether  infe  =  J.  or  inf 2  ±  -L.  We  shall  then  show  that  if  {intn)n 
is  a  descending  chain  then  the  sequence  (int%)n  eventually  stabilises.  So 
assume  that  (intn)n  is  a  descending  chain.  One  can  then  show  that  (int%)n 
is  a  descending  chain  (Exercise  4.9).  Next  suppose  by  way  of  contradiction 
that  (intfi)n  never  eventually  stabilises.  It  follows  that  there  exists  n\  >  0 
such  that: 

infi  £  [-oo,  oo]  for  all  n  >  ni 
It  furthermore  follows  for  all  n  >  n i  that  int^  must  have: 

sup(int£)  =  oo  or  inf(tnt^)  =  -oo 

Without  loss  of  generality  let  us  assume  that  all  n  >  ni  have  sup(inf^)  =  oo 
and  inf(inf^)  €  Z.  Hence  there  exists  ri2  >  ni  such  that: 

inf(inf^)  >  N  for  all  n>n2 

But  then  int%  =  int%2  for  all  n  >  n2  and  we  have  the  desired  contradiction. 
This  shows  that  A  is  a  narrowing  operator.  ■ 


4.3  Galois  Connections 

Sometimes  calculations  on  a  complete  lattice  L  may  be  too  costly  or  even 
uncomputable  and  this  may  motivate  replacing  L  by  a  simpler  lattice  M.  An 
example  is  when  L  is  the  powerset  of  integers  and  M  is  a  lattice  of  intervals. 
So  rather  than  performing  the  analysis  p  h  li  >  l2  in  L,  the  idea  will  be  to 
find  a  description  of  the  elements  of  L  in  M  and  to  perform  the  analysis 
p  h  mi  t>  m2  in  M.  To  express  the  relationship  between  L  and  M  it  is 
customary  to  use  an  abstraction  function 

a:  L-t  M 

giving  a  representation  of  the  elements  of  L  as  elements  of  M  and  a  concreti- 
sation  function 

7  :  M  — >  L 

that  expresses  the  meaning  of  elements  of  M  in  terms  of  elements  of  L.  We 
shall  write 

(L,a,  7,  M) 


or 


7 

L  _ ^  M 

a 
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Figure  4.6:  The  Galois  connection  (L,q,7,  M). 


for  this  setup  and  would  expect  that  a  and  7  should  be  somehow  related. 
We  shall  study  this  relationship  in  the  present  section  and  then  return  to  the 
connection  between  p  h  h  t>  I2  and  p  H  m\  >  m2  in  Section  4.5;  in  Section  4.4 
we  shall  study  the  systematic  construction  of  such  relationships. 

We  define  (L,  a,  7,  M)  to  be  a  Galois  connection  between  the  complete  lat¬ 
tices  (L,  C)  and  (M,  C)  if  and  only  if 

a  :  L  ->  M  and  7  :  M  L  are  monotone  functions 


that  satisfy: 


70  a  □  A  l.l  (4.8) 

a  o  7  C  A m.m  (4.9) 

Conditions  (4.8)  and  (4.9)  express  that  we  do  not  lose  safety  by  going  back 
and  forth  between  the  two  lattices  although  we  may  lose  precision.  In  the 
case  of  (4.8)  this  ensures  that  if  we  start  with  an  element  l  £  L  we  can  first 
find  a  description  a(l)  of  it  in  M  and  next  determine  which  element  7 (a(Z)) 
of  L  that  describes  a(Z);  this  need  not  be  l  but  it  will  be  a  safe  approximation 
to  l,  i.e.  I  C  7(a(Z)).  This  is  illustrated  in  Figure  4.6. 

Example  4.19  Let  V(Z)  =  (’P(Z),  C)  be  the  complete  lattice  of  sets  of 

integers  and  let  Interval  =  (Interval,  C)  be  the  complete  lattice  of  Figure 

4.2.  We  shall  now  define  a  Galois  connection 

CP(Z),  aZi,  7zi,  Interval) 


between  V{Z)  and  Interval. 
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The  concretisation  function  7zi  :  Interval  -4  P(Z)  is  defined  by 

7zi(int)  =  {z  €  Z  |  inf(tni)  <z<  sup(int)} 

where  inf  and  sup  are  as  in  Example  4.10.  Thus  7zi  will  extract  the  set  of  ele¬ 
ments  described  by  the  interval,  e.g.  7zi([0, 3])  =  {0, 1, 2, 3}  and  7zi([0,  oo])  = 
{z  €  Z  |  z  >  0}. 

The  abstraction  function  azi  :  T’(Z)  -4  Interval  is  defined  by 

n  (7\-i  L  VZ  =  Q 

ZI^  \  [inf'(Z),sup'(Z)]  otherwise 

where  inf'  and  sup'  are  as  in  Example  4.10.  Thus  azi  will  determine  the 
smallest  interval  that  includes  all  the  elements  of  the  set,  e.g.  azi({0, 1, 3})  = 
[0, 3]  and  azi({2  *  z  \  z  >  0})  =  [2,  oo]. 

Let  us  verify  that  ('P(Z),azi,7zi,  Interval)  is  indeed  a  Galois  connection.  It 
is  easy  to  see  that  azi  and  7zi  are  monotone  functions.  We  shall  next  prove 
that  (4.8)  holds,  i.e.  that  7zi  o  azi  3  A Z.Z.  If  Z  ^  0  we  have: 

7zi(azi  (Z))  =  7zi([inf'(2),sup'(Z)]) 

=  {ze  Z  |  inf  \Z)  <z<  sup'(Z)} 

2  Z 

For  Z  =  0  we  trivially  have  7zi(azi(0))  =  7zi(X)  =  0  so  we  have  proved 

(4.8) .  Intuitively,  this  condition  expresses  that  if  we  start  with  a  subset  of  Z, 
find  the  smallest  interval  containing  it,  and  next  determine  the  corresponding 
subset  of  Z,  then  we  will  get  a  (possibly)  larger  subset  of  Z  than  the  one  we 
started  with. 

Finally,  we  shall  prove  (4.9),  i.e.  that  azi  0  7zi  3  Xint.int.  Consider  first 
int  =  [zi ,  Z2]  where  we  have: 

azi(7zi([zi,Z2]))  =  azi({z  €  Z  |  zi  <  z  <  z2 }) 

=  [zi,z2] 

For  int  =  X  we  trivially  have  azi(7zi(X))  =  azi(0)  =  1  so  we  have  proved 

(4.9) .  Intuitively,  the  condition  expresses  that  if  we  start  with  an  interval, 

determine  the  corresponding  subset  of  Z,  and  next  find  the  smallest  interval 
containing  this  set,  then  the  resulting  interval  will  include  the  interval  we 
started  with;  actually  we  showed  that  the  two  intervals  are  equal.  ■ 


Adjunctions.  There  is  an  alternative  formulation  of  the  Galois  connec¬ 
tion  ( L ,  a,  7,  M)  that  is  frequently  easier  to  work  with.  We  define  (L,  a,  7,  M) 
to  be  an  adjunction  between  complete  lattices  L  =  ( L ,  C)  and  M  =  (M,  C) 
if  and  only  if 


a  :  L  -¥  M  and  7  :  M  -4  L  axe  total  functions 
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that  satisfy 


a(l)  Cm  l  C  7 (m) 


(4.10) 


for  all  l  £  L  and  m  £  M. 

Condition  (4.10)  expresses  that  a  and  7  “respect”  the  orderings  of  the  two 
lattices:  If  an  element  l  £  L  is  safely  described  by  the  element  m  £  M, 
i.e.  a(l)  C  m,  then  it  is  also  the  case  that  the  element  described  by  m  is  safe 
with  respect  to  I,  i.e.  I  C  7 (m). 


Proposition  4.20 

( L ,  a,  7,  M)  is  an  adjunction  if  and  only  if  (L,  a,  7,  M )  is  a  Galois 
connection. 


Proof  First  assume  that  (L,  a,  7,  M)  is  a  Galois  connection  and  let  us  show  that 
it  is  an  adjunction.  So  assume  first  that  a(l)  C  m;  since  7  is  monotone  we  get 
7 (a(l))  C  7 (m);  using  that  7003  A l.l  we  then  get  l  C  7 (a(l))  C  7(m)  as  required. 
The  proof  showing  that  l  C  7(771)  implies  a (l)  C  m  is  analogous. 

Next  assume  that  ( L ,  a,  7,  M)  is  an  adjunction  and  let  us  prove  that  it  is  a  Galois 
connection.  First  we  prove  that  700  3  A  l.l:  for  Z  6  L  we  trivially  have  n(l)  C  a(l) 
and  using  that  a(l)  C  m  =>  l  C  7 (m)  we  get  l  C  7(0(1))  as  required.  The  proof 
showing  that  a  a  7  C  A m.m  is  analogous.  To  complete  the  proof  we  also  have  to 
show  that  a  and  7  are  monotone.  To  see  that  a  is  monotone  suppose  that  l\  C  Z2; 
we  have  already  proved  that  70a  Zl-M.l  so  we  have  l\  C  l2  C  7(0(12));  using  that 
1  C  7(771)  =>  a(l)  C  77i  we  then  get  ar(Zi)  C  a(h).  The  proof  showing  that  q  is 
monotone  is  analogous.  ■ 


Galois  connections  defined  by  extraction  functions.  We 

shall  now  see  that  representation  functions  (introduced  in  Section  4.1)  can  be 
used  to  define  Galois  connections.  So  consider  once  again  the  representation 
function  /3  :V  ->  L  mapping  the  values  of  V  to  the  properties  of  the  complete 
lattice  L.  It  gives  rise  to  a  Galois  connection 

(V(V),  a,j,L) 


between  P(V)  and  L  where  the  abstraction  and  concretisation  functions  are 
defined  by 

o(V')  =  LJWhen 
7(1)  =  {u  €  V  I  P(v)  c  1} 

for  V'  C  V  and  l  £  L.  Let  us  pause  for  a  minute  to  see  that  this  indeed 
defines  an  adjunction: 


a(V')  C  l  o  |  v  e  V'}  C  l 

&  \/v  G  V'  :  0(v)  C  l 
&  V  C  7(1) 
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It  follows  from  Proposition  4.20  that  we  also  have  a  Galois  connection. 

A  special  case  of  the  above  construction  that  is  frequently  useful  is  when 
L  =  (V(D),  C)  for  some  set  D  and  we  have  an  extraction  function 

T] V  D 

mapping  the  values  of  V  to  their  descriptions  in  D.  We  will  then  define  the 
representation  function  (in  :  V  ->  V(D)  by  fin{v)  =  {r)(v)}  and  the  Galois 
connection  between  V(V)  and  V(D)  will  now  be  written 

where 

=  [){Pn(v)\v€V'}  =  {r,(v)\veV'} 

7 v(D')  =  {v  €  V  |  A,(t»)  C  D'}  =  {u  |  T)(v)  G  D'} 

for  V'  CV  and  D'  C  D. 

Example  4.21  Let  us  consider  the  two  complete  lattices  (V(Z),  C)  and 
(■p(Sign),  C)  where  Sign  =  {-,  0,  +};  see  Figure  4.7.  The  extraction  function 

sign  :  Z  Sign 

simply  defines  the  signs  of  the  integers  and  is  specified  by: 

(  -  if  2  <  0 

sign(z)  =  <  0  if  2  =  0 

l  +  if  2  >  0 

The  above  construction  then  gives  us  a  Galois  connection 

(■p(Z),  «sign ,  7sign,  'PC Sign)) 

with 

Qsign  (Z)  =  {sign(2)  I  2  e  Z} 

7sign (S)  =  {z  €  Z  I  Sign(2)  e  S} 

where  Z  CZ  and  S  C  Sign.  ■ 


4.3.1  Properties  of  Galois  Connections 

We  shall  present  three  interesting  results.  The  first  result  says  that  a  Galois 
connection  is  fully  determined  by  either  one  of  the  abstraction  and  concreti- 
sation  functions: 
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Figure  4.7:  The  complete  lattice  'P(Sign)  =  ('P(Sign),  C). 

Lemma  4.22  If  is  a  Galois  connection  then: 

(i)  a  uniquely  determines  7  by  7(m)  =  |_j{7  |  a(l)  C  m)  and  7  uniquely 
determines  a  by  a(l)  =  (l{m  M  E  7 (m)}. 

(ii)  a  is  completely  additive  and  7  is  completely  multiplicative. 

In  particular  a(X)  =  X  and  7(T)  =  T.  ■ 

Proof  To  show  (i)  we  shall  first  show  that  7  is  determined  by  a.  Since  (L,  a,  7,  M) 

is  an  adjunction  by  Proposition  4.20  we  have  7(m)  =  [J{i  |  l  C  7(771)}  =  | _ ] | 

a(l)  C  m}.  This  shows  that  a  uniquely  determines  7:  if  both  (L,  a,  71 ,  M)  and 
(L,a,  72,  M)  Eire  Galois  connection  then  71  (m)  =  [_j{7  |  a(l)  C  777}  =  72(771)  for  all 
77i  and  hence  71  =72. 

Similarly,  we  have  a(l )  =  D{m  I  a(0  E  m}  —  fl{m  I  i  E  7(m)}  and  this  shows 
that  7  uniquely  determines  a. 

To  show  (ii)  consider  L'  C  L\  using  Proposition  4.20  we  then  have 


a(|_J  L')  Cm  <=> 

|J  L'  C  7(771) 

<=> 

VI  €  L'  :  l  C  7(771) 

4* 

VI  €  L'  :  a{l)  C  m 

|_|{a(Z)  1 1  €  L'}  C 

and  it  follows  that  q((J  L')  =  [_|{a(Z)  | 

l  €  L'}. 

The  proof  that  7(n^O  =  n{7(m)  I  m  €  Af7}  is  analogous.  ■ 

Motivated  by  Lemma  4.22  we  shall  say  that  if  ( L ,  a,  7,  M)  is  a  Galois  con¬ 
nection  then  a  is  the  lower  adjoint  (or  left  adjoint)  of  7  and  that  7  is  the 
upper  adjoint  (or  right  adjoint)  of  a. 

The  next  result  shows  that  it  suffices  to  specify  either  a  completely  additive 
abstraction  function  or  a  completely  multiplicative  concretisation  function  in 
order  to  obtain  a  Galois  connection: 
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Lemma  4.23  If  a  :  L  ->  M  is  completely  additive  then  there  exists 
7  :  M  -+  L  such  that  (L,a,7,  M)  is  a  Galois  connection.  Similarly,  if 
7  :  M  -»  L  is  completely  multiplicative  then  there  exists  a  :  L  -4  M  such 
that  ( L ,  a,  7,  M)  is  a  Galois  connection.  ■ 

Proof  Consider  the  claim  for  a  and  define  7  by: 

7(m)  =  [_]{!'  |  a(l')  C  m) 

Then  we  have  a(l)  C  m  =>  1  6  {/'  |  a(l')  C  m}  =>  l  C  7(771)  where  the  last 
implication  follows  from  the  definition  of  7.  For  the  other  direction  we  first  observe 
that  l  C  7(771)  =>  a(l)  C  0(7(777))  because  a  is  completely  additive  and  hence 
monotone.  Now 


0(7(777))  =  a(|J{f'  |  o(f')  C  777}) 

=  L){a(0|a(0Em} 

C  777 

so  /  C  7(777)  =>  o(i)  C  777.  It  follows  that  (L,  o,  7,  M)  is  an  adjunction  and  hence  a 
Galois  connection  by  Proposition  4.20. 

The  proof  of  the  claim  for  7  is  analogous.  ■ 

The  final  result  shows  that  we  neither  lose  nor  gain  precision  by  iterating 
abstraction  and  concretisation:  ... 

Fact  4.24  If  ( )  is  a  Galois  connection  then  00700  =  0  and 

70007  =  7.  ■ 

Proof  We  have  A  l.l  C  7  o  a  and  since  a  is  monotone  we  get  a  C  90(70  a). 
Similarly  (a  o  7)  o  a  C  a  follows  from  a  o  7  C  Xm.m.  Thus  00700  =  0. 

The  proof  of  70007  =  7  is  analogous.  ■ 


Example  4.25  As  a  somewhat  more  complex  example  consider  the  com¬ 
plete  lattices  Interval  =  (Interval,  C)  and  'P(Sign)  =  ('P(Sign),  C)  of  Fig¬ 
ures  4.2  and  4.7,  respectively. 

Let  us  define  a  concretisation  function  71s  :  'P(Sign)  — >  Interval  by: 


7is({-,0,+})  =  [-00,00] 

7is({-,+})  =  [-00,00] 
7is({-})  =  [-00,-1] 
7is({+})  =  [l.oo] 


7is({-,0})  =  [-oo,0] 

7is({0,+})  =  [0,oo] 

7is({0})  =  [0,0] 

7is(0)  =  -L 


To  determine  whether  or  not  there  exists  an  abstraction  function 


c*is  :  Interval  -4  'P(Sign) 
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such  that  (Interval,  Qis,7is.T,(Sign))  is  a  Galois  connection,  we  shall  sim¬ 
ply  determine  whether  or  not  71s  is  completely  multiplicative:  If  it  is,  then 
Lemma  4.23  guarantees  that  there  does  indeed  exist  a  Galois  connection  and 
Lemma  4.22  tells  us  how  to  construct  the  abstraction  function.  If  71s  is 
not  completely  multiplicative  then  Lemma  4.22  guarantees  that  there  cannot 
exist  a  Galois  connection.  In  order  to  determine  whether  or  not  71s  is  com¬ 
pletely  multiplicative  we  shall  use  Lemma  A.4  of  Appendix  A:  It  is  immediate 
to  verify  that  T’(Sign)  is  finite  and  that  71s  satisfies  conditions  (i)  and  (ii) 
of  Lemma  A.4.  To  verify  condition  (iii)  we  need  to  compare  71s (Si  D  S2)  to 
Tis(Si)  ri7is(S2)  for  all  pairs  (Si,S2)  €  'P(Sign)  x  'P(Sign)  of  incomparable 
sets  of  signs,  i.e.  all  pairs  in  the  following  list: 

({-,0},  {-,+}),  ({-)  0},  (0,  +}),  ({-,(>},{+}), 

({-,+},  {0,+}),  ({-,+},  {0}),  ({0,  +},{-}), 

({-},{+}),  ({<>},{+}) 

In  checking  the  pair  ({-,0},  {-,+})  we  calculate 

7is({“,0}n  {-,+})  =  71s({"})  =  [-oo,-l] 

7is({“i  0})  n  71s ({-,  +})  =  [-oo,0]n[-oo,oo]  =  [-00,0] 

and  we  deduce  that  71s  is  not  completely  multiplicative.  Hence  according 
to  Lemma  4.22  we  cannot  find  any  a\s  :  Interval  — >  P(Sign)  such  that 
(Interval,  aiSjTiSi^Sign))  is  a  Galois  connection.  ■ 

The  mundane  approach  to  correctness.  We  shall  now  return 
to  further  motivating  that  the  cbnnection  between  L  and  M  should  be  a 
Galois  connection.  Recall  from  Section  4.1  that  the  semantic  correctness  of 
an  analysis  may  be  expressed  by  a  correctness  relation  R  between  the  values 
of  V  and  the  properties  of  L  or  it  may  be  expressed  by  a  representation 
function  P  mapping  the  values  of  V  to  their  description  in  L.  When  we 
replace  L  with  some  other  complete  lattice  M  we  would  obviously  like  the 
correctness  results  still  to  hold.  We  shall  now  see  that  if  there  is  a  Galois 
connection  ( L ,  a,  7,  M)  between  L  and  M  then  we  can  construct  a  correctness 
relation  between  V  and  M  and  a  representation  function  from  V  to  M. 

Let  us  first  focus  on  the  correctness  relations.  So  let  R:VxL->  {true,  false) 
be  a  correctness  relation  that  satisfies  the  conditions  (4.4)  and  (4.5)  of  Section 
4.1.  Further  let  (L,  a,  7,  M)  be  a  Galois  connection  between  the  complete 
lattices  L  and  M.  It  is  then  natural  to  define  S  :  V  x  M  — ^  {true, false)  by 

v  S  m  iff  v  R  (7(m)) 

and  we  shall  now  argue  that  this  is  a  correctness  relation  between  V  and  M 
fulfilling  conditions  corresponding  to  (4.4)  and  (4.5).  We  have 

(v  S  mi)  A  mi  C  m2  =*>  v  R  (7(mi))  A  7(mi)  C  7 (m2) 

v  R  (7 (m2)) 

=>  v  S  m2 


ft 
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using  that  7  is  monotone  and  that  R  satisfies  condition  (4.4);  this  shows  that 
S  also  satisfies  condition  (4.4).  Also  for  all  M'  CM  we  have 


(Vm  G  M'  :  v  S  m) 


=$>  (Vm  G  M1  :  v  R  (7(m))) 
=$>  v  R  (["*" |{7(m)  |  m  G  M'}) 

=>  v  R  (7(T1M')) 

=>  v  S  (J- Jm') 


using  that  7  is  completely  multiplicative  (Lemma  4.22)  and  that  R  satisfies 
condition  (4.5);  this  shows  that  S  also  satisfies  condition  (4.5).  Hence  S 
defines  a  correctness  relation  between  V  and  M. 


Continuing  the  above  line  of  reasoning  assume  now  that  R  is  generated  by  the 
representation  function  0  :  V  -»  L,  i.e.  v  Rl  0(v)  C  l.  Since  ( L ,  a,  7,  M) 
is  a  Galois  connection  and  hence  an  adjunction  (Proposition  4.20)  we  may 
calculate 


v  S  m  O  v  R  (7 (m)) 

0(v)  C  7 (m) 

(a  o  0)(y)  C  m 

showing  that  5  is  generated  by  a  o  0  :  V  ->  M.  This  shows  how  the  Galois 
connection  facilitates  the  definition  of  correctness  relations  and  representa¬ 
tion  functions  and  concludes  our  motivation  for  why  it  is  natural  to  require 
that  the  connection  between  L  aricf  M  is  specified  by  a  Galois  connection. 


4.3.2  Galois  Insertions 

For  a  Galois  connection  ( L ,  a,  7,  M)  there  may  be  several  elements  of  M  that 
describe  the  same  element  of  L,  i.e.  7  need  not  be  injective,  and  this  means 
that  M  may  contain  elements  that  are  not  relevant  for  the  approximation  of 
L. 

The  concept  of  Galois  insertion  is  intended  to  rectify  this:  (L,  a,  7,  M)  is  a 
Galois  insertion  between  the  complete  lattices  L  =  ( L ,  C)  and  M  =  ( M ,  C) 
if  and  only  if 

a  :  L  -¥  M  and  7  :  M  — >  L  are  monotone  functions 


that  satisfy: 


70  a  □  Xl.l 
a  07  =  A m.m 

Thus  we  now  require  that  we  do  not  lose  precision  by  first  doing  a  concretisa- 
tion  and  next  an  abstraction.  As  a  consequence  M  cannot  contain  elements 
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Figure  4.8:  The  Galois  insertion  (L,  a,  7,  M). 


that  do  not  describe  elements  of  L,  i.e.  M  does  not  contain  superfluous  ele¬ 
ments. 

Example  4.26  The  calculations  of  Example  4.19  show  that 

(P(Z) ,  aZi ,  7zi ,  Interval) 

is  indeed  a  Galois  insertion:  we  start  with  an  interval,  use  7zi  to  determine 
the  set  of  integers  it  describes  and  next  use  cczi  to  determine  the  smallest 
interval  containing  this  set  and  we  get  exactly  the  same  interval  as  we  started 
with.  ■ 

The  concept  of  a  Galois  insertion  is  illustrated  in  Figure  4.8  and  is  further 
clarified  by: 

Lemma  4.27  For  a  Galois  connection  ( L,a,j,M )  the  following  claims 
are  equivalent: 

(i)  ( L ,  a,  7,  M)  is  a  Galois  insertion; 

(ii)  a  is  surjective:  Vm  £  M  :  31  £  L  :  a(l)  =  m; 

(iii)  7  is  injective:  Vmi,ro2  €  M  :  7(mi)  =  7(7712)  =£-771!  =  77i2;  and 

(iv)  7  is  an  order-similarity:  V7n1,7n2  £  M  : 

7(7711)  C  7(7n2)  &  77li  C  7712.  ■ 

Proof  First  we  prove  that  (i)  =>  (iii).  For  this  we  calculate 

7(77H)  =  7(7712)  =>  a(7(f7!l))  =  0(7(7712))  =>  mi  =  7772 

where  the  last  step  follows  from  (i). 
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Next  we  prove  that  (iii)  =>  (ii).  For  m  6  M  we  have  7(01(7(771))  =  7(771)  by  Fact 
4.24  and  hence  0(7(771))  =  771  by  (iii). 

Now  we  prove  that  (ii)  =>  (iv).  That  771 1  C  7712  =>  7(7711)  C  7(7712)  is  immediate 
since  7  is  monotone.  Next  suppose  that  7(7711)  C  7(7712);  by  monotonicity  of  a  this 
gives  0(7(7711))  C  0(7(7712));  using  (ii)  we  can  write  mi  =  o(fi)  and  m2  =  o(Z2)  for 
some  Zi,Z2  €  L;  using  Fact  4.24  this  then  gives  mi  C  m2  as  desired. 

Finally  we  prove  that  (iv)  =>  (i).  For  this  we  calculate 

0(7(7711))  Cm2  &  7(mi)  C  7(7712)  mi  C  m2 

where  the  first  step  is  using  Proposition  4.20  and  the  last  step  is  using  (iv).  This 
shows  that  0(7(7711  j)  and  mi  have  the  same  upper  bounds  and  hence  are  equal.  ■ 

Lemma  4.27  has  an  interesting  consequence  for  a  Galois  connection  given  by 
an  extraction  function  77  :  V  ->  D:  it  is  a  Galois  insertion  if  and  only  if  77  is 
surjective. 


Example  4.28  Consider  the  complete  lattices  (V(Z),  C)  and  (P(Sign  x 
Parity),  C)  where  Sign  =  {-,0,+}  as  before  and  Parity  =  {odd,  even}. 
Define  the  extraction  function  signparity  :  Z  -4  Sign  x  Parity  by: 


signparity(z) 


■{ 


(sign(z),odd) 

(sign(z),even) 


if  z  is  odd 
if  z  is  even 


This  gives  rise  to  a  Galois  connection  (P(Z), osignparity ,  7signParity ,  V (Sign  x 
Parity)).  The  property  (0,odd)  describes  no  integers  so  clearly  signparity  is 
not  surjective  and  we  have  an  example  of  a  Galois  connection  that  is  not  a 
Galois  insertion.  ■ 


Construction  of  Galois  insertions.  Given  a  Galois  connection 
(i,a,7,  M)  it  is  always  possible  to  obtain  a  Galois  insertion  by  enforcing 
that  the  concretisation  function  7  is  injective.  Basically,  this  amounts  to 
removing  elements  from  the  complete  lattice  M  using  a  reduction  operator 

q  :  M  M 

defined  from  the  Galois  connection.  We  have  the  following  result: 


Proposition  4.29 

Let  (L,a,7,  M)  be  a  Galois  connection  and  define  the  reduction 
operator  q  :  M  -4  M  by 

?(m)  lira)  =  7(m')} 

Then  q[M ]  =  ({<r(m)  |  m  €  M},Qm)  is  a  complete  latcice  and 
(L,a,7,<;[M])  is  a  Galois  insertion. 
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Figure  4.9:  The  reduction  operator  q  :  M  -4  M. 

This  is  illustrated  in  Figure  4.9:  The  idea  is  that  two  elements  of  M  are 
identified  by  <;  if  they  map  to  the  same  value  by  7;  in  particular,  m  and 
a(7(mj)  will  be  identified. 

In  preparation  for  the  proof  we  shall  first  show  the  following  two  results: 
Fact  4.30  Let  (L,  a,  7,  M)  be  a  Galois  connection.  Then 
a[L]  =  ({<*(l)\UL},nM) 


is  a  complete  lattice.  ■ 

Proof  Clearly  o[L]  C  M  is  partially  ordered  by  the  ordering  Cm  of  M  =  ( M ,  Cm). 
We  now  want  to  show  for  M'  C  a[L ]  C  M  that 

UaWM'  =  UMM' 

We  first  show  that  |JM  M'  e  o[L\  which  means  that  there  exists  l  £  L  such  that 
a(l)  =  |JM  M'.  For  this  take  l  =  |JL  7[Af']  which  clearly  exists  in  L.  Since 
00700  =  0  (Fact  4.24)  and  o  is  completely  additive  (Lemma  4.22)  we  then  have 

«(0  =  a(LL7[M']) 

=  UMQb[M']] 

=  U  mm' 

thus  showing  [JM  M'  €  o[L].  Since  )JM  M'  is  the  least  upper  bound  of  M'  in  M 
it  follows  that  it  also  is  in  a[L].  By  Lemma  A. 2  we  then  have  the  result.  ■ 

Fact  4.31  If  (L,  0,7,  M)  is  a  Galois  connection  and 
q(m)  =  f|{m'  |  7(771')  =  7(m)} 
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then 

q(m)  =  a(y(m)) 

and  hence  a[L\  =  ?[M].  ■ 

Proof  We  have  ?(m)  C  0(7(771))  because  7(m)  =  7(0(7(771)))  using  Fact  4.24. 
That  0(7(771))  C  c(m)  is  equivalent  to  7(771)  C  7(5(771))  using  Proposition  4.20  and 
7 (5(771))  =  f“| {7(771')  |  7(771')  =  7(771)}  —  7(771)  follows  from  Lemma  4.22. 

Next  consider  o(i)  for  l  €  L;  by  Fact  4.24  we  have  a(l)  =  a(y(a(l)))  and  hence 
a(l)  =  c(a(/));  this  shows  a[L]  C  ?[M].  Finally  consider  5(771)  for  m  6  M;  then 
5(771)  =  0(7(771));  this  shows  c[M]  C  ot[M}.  ■ 

We  now  turn  to  the  proof  of  Proposition  4.29: 

Proof  Facts  4.30  and  4.31  give  that  ?[M]  =  a[L]  is  a  complete  lattice.  Since 
(L,  a,  7,  M)  is  an  adjunction  (Proposition  4.20)  it  follows  that  also  (L,  a,  7,  o[L]) 
is.  Since  a  is  surjective  on  a[L]  it  follows  from  Lemma  4.27  that  we  have  a  Galois 
insertion.  ■ 

Reduction  operators  defined  by  extraction  functions.  We 
shall  now  specialise  the  construction  of  Proposition  4.29  to  the  setting  where 
a  Galois  connection  0 P(V),av,yri,V(D ))  is  given  by  an  extraction  function 
T)  :V  D.  Then  the  reduction  operator  ^  is  given  by 

<„(£>')  =  0'n  V[V] 

where  tj[V ]  =  {77(17)  |  v  €  V}  denotes  the  image  of  rj  and  furthermore  qv[P{D)] 
is  isomorphic  (see  Appendix  A)  to  V(tj[V])  (see  Exercise  4.14).  The  result¬ 
ing  Galois  insertion  will  therefore  be  isomorphic  to  (V{V),av,'yr,,V(Ti[V])): 
Formally,  the  Galois  connection  (Xi, 07,71, Mi)  is  isomorphic  to  the  Ga¬ 
lois  connection  (£2,02, 72,  M2)  when  there  are  isomorphisms  0l  •  Xi  ->  £2 
and  0m  :  Mi  M2  (see  Appendix  A)  such  that  a2  =  6m  0  01  o  Of1  and 

72  =  0l  °  7i  0  ®~xf  ■ 

Example  4.32  Returning  to  Example  4.28  we  can  use  the  above  tech¬ 
nique  to  construct  a  Galois  insertion.  Now 

signparityfZ]  =  {(-,  odd),  (-,  even),  (0,  even),  (+,  odd),  (+,  even)} 

showing  that  (P(Z),osignp3rity,7signparity,??(signparity[Z]))  is  the  resulting  Ga¬ 
lois  insertion.  ■ 


4.4  Systematic  Design  of  Galois  Connections 

Sequential  composition.  When  developing  a  program  analysis  it  is 
often  useful  to  do  so  in  stages:  The  starting  point  will  typically  be  a  com¬ 
plete  lattice  (Lq)  Q  fairly  closely  related  to  the  semantics;  an  example  is 


240 


ABSTRACT  INTERPRETATION 


(V(V),C).  We  may  then  decide  to  use  a  more  approximate  set  of  prop¬ 
erties  and  introduce  the  complete  lattice  [L\ ,  C)  related  to  Lq  by  a  Galois 
connection  (Lo,ari,7i,Li).  This  step  can  then  be  repeated  any  number  of 
times:  We  replace  one  complete  lattice  Li  of  properties  with  a  more  ap¬ 
proximate  complete  lattice  (£i+1,[I)  related  to  L,  by  a  Galois  connection 
(Li,ai+i,7i+i,£i+i).  This  process  will  stop  when  we  have  an  analysis  with 
the  required  computational  properties.  So  the  situation  can  be  depicted  as 
follows: 

7i  72  73  7 k 

Lf)  _  Li  _  z<2  _  ' '  ■  _  Tfc 

£*1  *  <*2  *  Q3  *  Oik  ‘ 

The  above  sequence  of  approximations  of  the  analysis  could  as  well  have  been 
done  in  one  step,  i.e.  the  “functional  composition”  of  two  Galois  connections 
is  also  a  Galois  connection.  Formally,  if  (Lo>£*i,7i>Ti)  and  (Tj, 02,72,^2) 
are  Galois  connections,  then  also 

(Z,0,C*2  °«l,7l  °72,^2) 

is  a  Galois  connection.  To  verify  this  we  simply  observe  that  012(0:1  (Zo))  E± 
h  •O’  ai(Z0)  E  72(^2)  O-  lo  C  71(72(^2))  and,  using  Proposition  4.20,  this 
shows  the  result.  A  similar  result  holds  for  Galois  insertions  because  the 
functional  composition  of  surjective  functions  yields  a  surjective  function. 

Each  of  the  Galois  connections  (Lf,ai+i,ji+\,Li+i)  may  have  been  obtained 
by  combining  other  Galois  connections  and  we  shall  shortly  introduce  a  num¬ 
ber  of  techniques  for  doing  so.  We  shall  illustrate  these  techniques  in  a  se¬ 
quence  of  examples  that  in  the  end  will  give  us  a  finite  complete  lattice  that 
has  turned  out  to  be  very  useful  in  practice  for  performing  an  Array  Bound 
Analysis. 

Example  4.33  One  of  the  components  in  the  Array  Bound  Analysis  is 
concerned  with  approximating  the  difference  in  magnitude  between  two  num¬ 
bers  (typically  the  bound  and  the  index).  We  shall  proceed  in  two  stages: 
First  we  shall  approximate  pairs  (21,22)  of  integers  by  their  difference  in 
magnitude  |^i|  — 12:2|  and  next  we  shall  further  approximate  this  difference 
using  a  finite  lattice.  The  two  Galois  connections  will  be  defined  by  extrac¬ 
tion  functions  and  they  will  then  be  combined  by  taking  their  functional 
composition. 

The  first  stage  is  specified  by  the  Galois  connection 
(P(Z  x  Z),adifF,7difr,T,(Z)) 

where  diff  :  Z  x  Z  ->  Z  is  the  extraction  function  calculating  the  difference 
in  magnitude: 


diff(2i,22)  =  \zi\-\z2\ 
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The  abstraction  and  concretisation  functions  c*diff  and  -ydifF  will  then  be 

atdiff(ZZ)  =  {|zi|-|z2|  \  (zi,z2)  e  ZZ) 
lm{Z)  =  {(zuz2)  \  \zi\-\z2\€Z} 

for  ZZ  C  Z  x  Z  and  Z  C  Z. 

The  second  stage  is  specified  by  the  Galois  connection 
(V(Z),  Qr3nge,  7range,  ^(Range)) 

where  Range  =  {<— 1,  —1,0,  +1,>+1}.  The  extraction  function  range  :  Z  -4 
Range  clarifies  the  meaning  of  the  elements  of  Range: 

'  <-l  if  z  <  -1 
-1  if  z  =  — 1 
range(z)  =  0  if  z  =  0 

+1  if  z  =  1 
>+l  if  z  >  1 

The  abstraction  and  concretisation  functions  arange  and  7range  will  then  be 

a,3nge(Z)  =  {range(z)  |  z  €  Z} 

7rang e{R)  =  {z  |  range(z)  €  R} 

for  Z  C  Z  and  R  C.  Range. 

We  then  have  that  the  functional  composition 

(P(Z  x  Z ) ,  or ,  tr ,  T7 (Range) ) 

where  or  =  arange  °  Odiff  and  tr  =  7a, fr  °  7range>  is  a  Galois  connection.  We 
obtain  the  following  formulae  for  the  abstraction  and  concretisation  functions: 

aR(ZZ)  =  {range(|zi|  -  |z2|)  |  (zi,z2)  €  ZZ) 

7R (R)  =  {(zi,z2)  |  range(|zi|-|z2|)  e  R} 

Using  Exercise  4.15  we  see  that  this  is  the  Galois  connection  specified  by  the 
extraction  function  range  o  diff  :ZxZ->  Range.  ■ 

A  catalogue  of  combination  techniques.  We  have  seen  that  the 
“functional  (or  sequential)  composition”  of  Galois  connections  gives  rise  to 
a  new  Galois  connection.  It  is  also  useful  to  be  able  to  do  “parallel  com¬ 
binations”  and  this  will  be  the  topic  for  the  remainder  of  this  section.  We 
may  have  analyses  for  the  individual  components  of  a  composite  structure 
and  may  want  to  combine  them  into  an  analysis  for  the  whole  structure;  we 
shall  see  two  techniques  for  that:  the  independent  attribute  method  and  the 
relational  method.  We  shall  also  show  how  Galois  connections  can  be  used 
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to  approximate  the  total  function  spaces  and  the  monotone  function  spaces. 
Alternatively,  we  may  have  several  analyses  of  the  same  structure  and  may 
want  to  combine  them  into  one  analysis  and  here  the  direct  product  and  the 
direct  tensor  product  allow  us  to  do  that.  Using  the  notion  of  Galois  inser¬ 
tions  this  leads  to  a  study  of  the  reduced  product  and  the  reduced  tensor 
product. 

The  benefit  of  having  such  a  catalogue  of  techniques  is  that  a  relative  small 
set  of  “basic”  analyses,  whose  correctness  have  been  established,  can  be  used 
to  construct  rather  sophisticated  analyses  and,  from  an  implementation  point 
of  view,  opens  up  the  possibility  of  reusing  existing  implementations.  Finally, 
it  is  worth  stressing  that  the  complete  lattices  used  in  program  analysis  ob¬ 
viously  can  be  constructed  without  using  these  techniques  but  that  it  often 
provides  additional  insights  to  view  them  as  combinations  of  simpler  Galois 
connection. 

4.4.1  Component- wise  Combinations 

The  first  techniques  we  shall  consider  are  applicable  when  we  have  several 
analyses  of  individual  components  of  a  structure  and  we  want  to  combine 
them  into  a  single  analysis. 

Independent  attribute  method.  Let  (Li,  £*1,71,  Mi)  and  (L2,a2, 
72,  M2)  be  Galois  connections.  The  independent  attribute  method  will  then 
give  rise  to  a  Galois  connection  '•  - 

(Li  x  L2,a,'y,Mi  x  M2) 

where: 

&(hih)  =  (<*i(h),  ot2(l2)) 

7  (mi,m2)  =  (7i(mi), 72(7712)) 

To  see  that  this  indeed  does  define  a  Galois  connection  we  simply  calculate 

E  (mi,m2)  <=>  (ai(h),a2(l2))  C  (mi,m2) 

<£>  ai(h)C.mi  A  a2(l2)Qm2 
4=>  /1  Q7i(mi)  A  l2C  72(7712) 

<=>  {I1J2)  E  (7i("»i).72(m2)) 

(h,k)Q'r(m  1,7712) 

and  use  Proposition  4.20.  A  similar  result  holds  for  Galois  insertions  (Exercise 
4.17). 


f 


4.4  Systematic  Design  of  Galois  Connections 


243 


Example  4.34  The  Array  Bound  Analysis  will  contain  a  component  that 
performs  a  Detection  of  Signs  Analysis  on  pairs  of  integers.  As  a  starting 
point,  we  take  the  Galois  connection 

(P ( Z) ,  (*sign  i  7sign )  P ( Sign) ) 

specified  by  the  extraction  function  sign  in  Example  4.21.  It  can  be  used 
to  analyse  both  components  of  a  pair  of  integers  so  using  the  independent 
attribute  method  we  will  get  a  Galois  connection 

(V(Z)  x  'P (Z) ,  ass ,  7ss ,  P (Sign)  x  P(Sign)) 

where  ass  and  7ss  are  given  by 

ass(Zi,Z2)  =  ({sign(z)  |  2  €  Zi},{slgn{z)  \  z  e  Z2}) 

7ss (Si,S2)  =  ({ z  |  sign(.z)  €  Si},  {z  |  sign(z)  €  S2}) 

where  Zt  C  Z  and  S<  C  Sign. 

This  Galois  connection  cannot  be  described  using  an  extraction  function  be¬ 
cause  neither  V{Z)  x  V(Z)  nor  P(Sign)  x  P(Sign)  is  a  powerset.  However, 
they  are  both  isomorphic  to  powersets: 

P(Z)xp(Z)  ~  P({l,2}xZ) 

P(Sign)  x  P(Sign)  =  P({1,2}  x  Sign) 

By  defining  the  extraction  function  twosigns  :  {1, 2}  x  Z  ->  {1,2}  x  Sign 
using  the  formula  twosigns(i,  z)  =  (i,sign(.z))  we  obtain  a  Galois  connection 

(P({1>2}  X  Z) ,  OtwosignS)  TtwosignS)  P({1)  2}  x  Sign)) 

that  is  isomorphic  to  (P(Z)  x  P(Z),  aSs, 7ss,  P(Sign)  x  P(Sign)). 

In  general  the  independent  attribute  method  often  leads  to  imprecision.  An 
expression  like  (x,-x)  in  the  source  language  may  have  a  value  in  {{z,  -z)  | 
z  6  Z}  but  in  the  present  setting  where  we  use  V(Z)  x  V(Z)  to  represent  sets 
of  pairs  of  integers  we  cannot  do  better  than  representing  {(z,  —z)  \  z  €  Z} 
by  (Z,  Z)  and  hence  the  best  property  describing  it  in  the  analysis  of  Example 
4.34  will  be  ass(Z,  Z)  =  ({-,  0,  +},  0,  +}).  Thus  we  lose  all  information 

about  the  relative  signs  of  the  two  components.  ■ 

Relational  method.  In  the  independent  attribute  method  there  is  ab¬ 
solutely  no  interplay  between  the  two  pairs  of  abstraction  and  concretisation 
functions.  It  is  possible  to  do  better  by  allowing  the  two  components  of  the 
analysis  to  interact  with  one  another  so  as  to  get  more  precise  descriptions. 

Let  (P(Vi),ai,7i,P(Di))  and  (V(y2),a2,i2,V(D2))  be  Galois  connections. 
The  relational  method  will  give  rise  to  the  Galois  connection 

(m  x  V2),a,7 ,P(Di  xD2)) 


u 
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where 


a(VV)  =  □{«!({«!»  x  a2({u2})  |  {vuv2)  G  VV} 

7 (DD)  =  {(«i,v2)  |  c*i({i>i})  x  a2({u2})  C  DD} 

where  VV  C  Vi  x  V2  and  DD  C  Di  x  D2.  Let  us  check  that  this  does  indeed 
define  a  Galois  connection.  From  the  definition  it  is  immediate  that  a  is 
completely  additive  and  hence  that  there  exists  a  Galois  connection  (Lemma 
4.23).  It  remains  to  show  that  7  (as  defined  above)  is  the  upper  adjoint  of 
a.  For  this  we  can  use  Lemma  4.22  and  calculate 

7 {DD)  =  {(ni,i/2)  |  ai({t>i})  x  a2({v2})  C  DD} 

=  {(vi,v2)\a({(vi,v2)})CDD} 

=  \J{VV\a(VV)CDD} 

where  we  have  used  that  a  is  completely  additive.  This  shows  the  required 
result. 

It  is  instructive  to  see  how  the  relational  method  is  simplified  if  the  Galois 
connections  (V(Vi),ai,ji,V(Di))  are  given  by  extraction  functions  iji  :  V, 

Di,  i.e.  if  a<(V7)  =  {??i(ui)  |  v{  €  V!)  and  7;(i5')  =  {uf  |  rn(vi)  G  D'}.  We 
then  have 


a(VV)  =  {(t)i{vi),t)2M)  I  (vi,v2)  G  VV} 

7 (DD)  =  {(«i,u2)  |  (771  (vi),r]2 (v2))  e  DD} 

which  also  can  be  obtained  directly  from  the  extraction  function  77 :  Vj  x  V2  -> 
Di  x  D2  defined  by  v(vi,v2)  =  (r]i{vi),r]2(v2)). 

Example  4.35  Let  us  return  to  Example  4.34  and  show  how  the  rela¬ 
tional  method  can  be  used  to  construct  a  more  precise  analysis.  We  will  now 
get  a  Galois  connection 

(V(Z  x  Z),ass.,7ss',T,(Sign  x  Sign)) 

where  ass'  and  7ss'  are  given  by 

ass'(ZZ)  =  {(sign(zi),sign(z2))  |  (zuz2)  G  ZZ} 

7ss '(SS)  =  {(zi,z2)  |  (sign(zi),sign(z2))  G  SS} 

where  ZZ  C  Z  x  Z  and  SS  C  Sign  x  Sign.  This  corresponds  to  us¬ 
ing  an  extraction  function  twosigns'  :  Z  x  Z  ->  Sign  x  Sign  defined  by 
twosigns'(2i,z2)  =  (sign(zi),sign(*2)). 

Once  again  consider  the  expression  (x,-x)  in  the  source  language  that  has 
a  value  in  {(z,  - z)  |  z  G  Z}.  In  the  present  setting  {{z,  —  z)  \  z  G  Z}  is  an 
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element  of  V(Z  x  Z)  and  it  is  described  by  the  set  ass'({(z,  —  z)  |  2  G  Z})  = 
{(-,+),  (0,0),  (+,-)}  of  ^(Sign  x  Sign).  Hence  the  information  about  the 
relative  signs  of  the  two  components  is  preserved.  This  will  be  the  Galois 
connection  that  we  will  use  in  our  further  development  of  the  Array  Bound 
Analysis.  ■ 


The  above  treatment  of  the  relational  method  can  be  extended  in  a  very 
general  way.  Let  us  write  V{V\)®V(V2)  for  V(Vi  x  V2)  and  similarly  V(D\)® 
V(D2)  for  V{D\  x  £>2)-  It  is  possible  to  perform  a  more  general  development 
using  a  notion  of  tensor  product  for  which  L\  <g>  L2  exists  even  when  the 
complete  lattices  L\  and  £2  are  not  powersets.  We  refer  to  the  Concluding 
Remarks  for  information  about  this. 

Total  function  space.  In  Appendix  A  it  is  established  that  if  £  is  a 
complete  lattice  then  so  is  the  total  function  space  S  -4  £  for  S  being  a  set. 
We  have  a  similar  result  for  Galois  connections: 

Let  (£,  a,  7,  M)  be  a  Galois  connection  and  let  5  be  a  set.  Then  we  obtain 
a  Galois  connection 

(S-t  £,a',7',5->  A£) 

by  taking 

a' {f)  =  ao  f 

7  '(g)  =  7°  9 

To  see  this  we  first  observe  that  a'  and  7'  are  monotone  functions  because  a 
and  7  are;  furthermore 

7' («'(/))  =  7  o  a  o  /  □  / 

a'(7'(s))  =  a°7° Q  Q  Q 

follow  since  (£,a,7,  M)  is  a  Galois  connection.  A  similar  result  holds  for 
Galois  insertions. 

Example  4.36  Assume  that  we  have  some  analysis  mapping  the  program 
variables  to  properties  from  the  complete  lattice  £,  i.e.  operating  on  the  ab¬ 
stract  states  Var  -4  £.  Given  a  Galois  connection  (£,  a,  7,  M )  the  above 
construction  will  show  us  how  the  abstract  states  of  Var  ->  L  are  approxi¬ 
mated  by  the  abstract  states  of  Var  -4  M.  ■ 

Monotone  function  space.  In  Appendix  A  it  is  established  that  the 
monotone  function  space  between  two  complete  lattices  is  a  complete  lattice. 
We  have  a  similar  result  for  Galois  connections: 

Let  (£i,ai,7i, Afi)  and  (£2,02,72, M2)  be  Galois  connections.  Then  we 
obtain  the  Galois  connection 


(£1  ->  £2,0, 7, Mi  -4  M2) 
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by  taking 

<*(/)  =  a2  o  /  o 

7(5)  =  72°  9°ai 

To  check  this  we  first  observe  that  the  functions  a  and  7  are  monotone 
because  a2  and  y2  are;  next  we  calculate 

7 («(/))  =  (72  °  <*2)  o  /  o  (7l  o  Ql)  □  / 

<*(7(0))  =  (<*2  0  72)  0  5  0  (ai  0  71)  Q  9 

using  the  monotonicity  of  /  :  L\  -4  L2  and  g  :  Mi  ->  M2  together  with  (4.8) 

and  (4.9).  A  similar  result  holds  for  Galois  insertions  (Exercise  4.17). 

This  construction  is  illustrated  by  the  following  commuting  diagrams: 


«(/)  '  9 


4.4.2  Other  Combinations 

So  far  our  constructions  have  shown  how  to  combine  Galois  connections  deal¬ 
ing  with  individual  components  of  the  data  into  Galois  connections  dealing 
with  composite  data.  We  shall  now  show  how  two  analyses  dealing  with  the 
same  data  can  be  combined  into  one  analysis;  this  amounts  to  performing  two 
analyses  in  parallel.  We  shall  consider  two  variants  of  this  analysis,  one  “cor¬ 
responding”  to  the  independent  attribute  method  and  one  “corresponding” 
to  the  relational  method. 

Direct  product.  Let  (£,,07,71, Mi)  and  (L,a2,j2,  M2)  be  Galois  con¬ 
nections.  The  direct  product  of  the  two  Galois  connection  will  be  the  Galois 
connection 

(L,a,7,Mi  x  M2) 

where  a  and  7  are  given  by: 

“(0  =  (ai(l),a2(l)) 

7(mi,m2)  =  71  (n*i  )n72  (m2) 
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To  see  that  this  indeed  defines  a  Galois  connection  we  calculate 

a(Z)C  (7711,7712)  <=>  ai(!)CmiAa2(l)Eff>2 

<$■  l  E  7i(mi)  A  l  C  72(ro2) 
l  C  7(7711,7712) 

and  then  use  Proposition  4.20  to  get  the  result. 

Example  4.37  Let  us  consider  how  this  construction  can  be  used  to  com¬ 
bine  the  detection  of  signs  analysis  for  pairs  of  integers  given  in  Example  4.35 
with  the  analysis  of  difference  in  magnitude  given  in  Example  4.33.  We  get 
the  Galois  connection 

(V(Z  x  Z),asSE,7ssR,7>(Sign  x  Sign)  x  P(Range)) 

where  assR  and  7ssr  are  given  by: 

<xssr(ZZ)  =  ({(signer), sign(z2))  |  (21,22)  €  ZZ}, 
{range(|zi|-|*2|)  |  (zuz2)  G  ZZ}) 

7SSR (SS,R)  =  {(21,22)  |  (sign (zi), sign (z2))  G  SS} 
n{(2i,22)  |  range(|zij  — |z2|)  G  R} 

Note  that  the  expression  (x,  3*x)  in  the  source  language  has  a  value  in 
{(z, 3  *  2)  |  2  G  Z}  which  is  described  by  <*ssr({(2,3  *  2)  |  2  G  Z})  = 
({(-,  -),  (0, 0),  (+,  +)},  {0,  <-l}).  Thus  we  do  not  exploit  the  fact  that  if  the 
pair  is  described  by  (0,0)  then  the  difference  in  magnitude  will  indeed  be 
described  by  0  whereas  if  the  pair  is  described  by  (-,  -)  or  (+,  +)  then  the 
difference  in  magnitude  will  indeed  be  described  by  <-l.  ■ 

Direct  tensor  product.  In  the  direct  product  there  is  no  interplay 
between  the  two  abstraction  functions  and  as  we  saw  above  this  gives  rise 
to  the  same  loss  of  precision  as  in  the  independent  attribute  method.  It 
is  possible  to  do  better  by  letting  the  two  components  interact  with  one 
another.  Again  we  shall  only  consider  the  simple  case  of  powersets  so  let 
{V{V),ai,H,V{Di))  be  Galois  connections.  Then  the  direct  tensor  product 
is  the  Galois  connection 

(V(V),a,1,V(DLxD2)) 

where  a  and  7  are  defined  by: 

a(V')  =  (J{c2i({u})  x  q2({u})  I  v  G  V'} 

7 (DD)  =  {u  |  c*i({u})  x  a2({u})  C  DD) 
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where  V'  C  V  and  DD  C  D\  x  D2.  To  verify  that  this  defines  a  Galois 
connection  we  calculate 

a(V')CDD  <£>  V»  €  V' :  Qi({u})  x  a2({u})  C  DD 
<3-  Vu  £  V'  :  v  £  7 (DD) 

V'C'y(DD) 

and  then  use  Proposition  4.20. 

The  construction  can  be  simplified  if  the  two  Galois  connections  ( V(V),ai , 
7 i,V(Di))  are  given  by  extraction  functions  rn  :  V  ->  A,  i  e.  if  Qt(T')  = 
{rji(v)  |  v  £  V'}  and  7i(A)  =  {u  |  r)i(v)  £  £)•}.  Then  we  have 

a(V')  =  {(m(v)Mv))  \V£V'} 

7 (DD)  =  {v  \  (t)i(v),ti2(v))  £  DD} 

which  also  can  be  obtained  directly  from  the  extraction  function  rj  :  V  -> 
D i  x  D2  defined  by  rj(v)  =  (??i (v),r]2(v)). 

Example  4.38  Let  us  return  to  Example  4.37  and  show  how  the  direct 
tensor  product  gives  a  more  precise  analysis.  We  will  now  get  a  Galois  con¬ 
nection 

(P(Z  x  Z),aSsR',7ssR',T>(Sign  x  Sign  x  Range)) 

where 

assK'(ZZ)  =  {(sign(2;1),sigh(z2),range(|z1|  — 1^2|))  |  {zuz2)  £  ZZ} 
nrssn'iSSR)  =  {{zi,z2)  |  (sign(zi),sign(z2),range(|z1|-|z2|))  £  SSR} 

for  ZZ  C  Z  x  Z  and  SSR  C  Sign  x  Sign  x  Range. 

It  is  worth  pointing  out  that  this  Galois  connection  is  also  obtainable  from 
the  extraction  function 

twosignsrange  :ZxZ->  Sign  x  Sign  x  Range 

defined  by  twosignsrange(zi,z2)  =  (sign(zi),sign(z2),range(|zi|-|z2|)). 

Returning  to  the  precision  of  the  analysis  we  will  now  have  ccssr'  ({(z>  3  *  z)  \ 
z  £  Z})  =  <— 1),  (0, 0, 0),  (+,  +,  <-l)}  and  hence  have  a  more  precise 

description  than  in  Example  4.37. 

However,  it  is  worth  noticing  that  the  above  Galois  connection  is  not  a  Ga¬ 
lois  insertion.  To  see  this  consider  the  two  elements  0  and  {(0, 0,  <-l)}  of 
■p(Sign  x  Sign  x  Range)  and  observe  that 

7ssr'(0)  =  0  =  7ssr'({(0,0,  <-l)}) 


Thus  7ssr'  is  not  injective  and  hence  Lemma  4.27  shows  that  we  do  not  have 
a  Galois  insertion.  ■ 
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Reduced  product  and  reduced  tensor  product.  The  con¬ 
struction  of  Proposition  4.29  gives  us  a  general  method  for  turning  a  Galois 
connection  into  a  Galois  insertion.  This  technique  can  now  be  combined 
with  the  other  techniques  for  combining  Galois  connections  and  this  is  of 
particular  interest  for  the  direct  product  and  the  direct  tensor  product. 

Let  (L, <*1,71,  Mi)  and  (L,a 2, 72, M2)  be  Galois  connections.  Then  the  re¬ 
duced  product  is  the  Galois  insertion 

(L,  a,  7,  ?[Mi  x  M2]) 

where 

a(l)  =  (ai(0,O2(/)) 

7(7711,  m2)  =  7l(jTli)  fl  72(012) 

?(mi,m2)  =  f]{(mi,m2)  |  7i(mi)  n72(m2)  =  7i(mi)  n72(m2)} 

To  see  that  this  is  indeed  a  Galois  insertion  recall  that  we  already  know 
that  the  direct  product  (£,<*,7,  Mi  x  M2)  is  a  Galois  connection  and  that 
Proposition  4.29  then  shows  that  (L,  a,7,c[Mi  x  M2])  is  a  Galois  insertion. 

Next  let  (V(V),ai,‘yi,'P(Di))  be  Galois  connections.  Then  the  reduced  tensor 
product  is  the  Galois  insertion 

(V(V),a,1,<;[P(D1  x  D2)]) 

where 

a(V')  =  jJWM)  x  MM)  |  U  6  P'} 

7 (DD)  =  {u  |  <*i({u})  x  <*2({u})  C  DD} 

<;{DD)  =  {]{D0\1{DD)=1{Diy)} 

Again  it  follows  from  Proposition  4.29  that  this  is  indeed  a  Galois  insertion. 

Example  4.39  Let  us  return  to  Example  4.38  where  we  noted  that  the 
complete  lattice  P(Sign  x  Sign  x  Range)  contains  more  than  one  element 
that  describes  the  empty  set  of  V(Z  x  Z).  The  superfluous  elements  will 
be  removed  by  the  construction  of  Proposition  4.29.  The  function  cssr'  will 
amount  to 

Cssr '{SSR)  =  I  7ssr '(SSR)  =  7ssr >(SSR')} 

where  SSR ,  SSR!  C  Sign  x  Sign  x  Range.  In  particular,  $ssr'  will  map  the 
singleton  sets  constructed  from  the  16  elements 

(~,0,  <-i),  (-,0,-1),  (-,0,0), 

(0,  — , 0),  (0,  -,  +1),  (0,  -,  >+1), 

(0,0,  <-l),  (0,0,  -1),  (0,0, +1),  (0,0,  >+l), 

(0,+,0),  (0,+,+l),  (0,+,>+l), 

(+> 0,  <-i),  (+,0,-1),  (+,0,0) 
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to  the  empty  set.  The  remaining  29  elements  of  Sign  x  Sign  x  Range  are 


(-,-,<-1), 

(-, 

(- 

,-,0), 

1+1), 

(-, 

-,>+l), 

(-,  o.+l), 

(-, 

© 

V 

+ 

(-,+,<-!), 

(-, 

+,-l), 

(- 

,+,o), 

+1), 

(-. 

+,>+1), 

(o, <-i), 

(0, 

-1), 

(0, 

O 

3 

(o.+> 

<-l). 

(0, 

+,-l), 

(+,-,<-!). 

(+> 

-.-1), 

(+> 

-  0), 

(+."> 

+1)> 

(+. 

-,>+!), 

(+,0,+l), 

(+ 1 

0,>+l), 

(+> +><-!)> 

(+> 

(+> 

+.  0), 

(+.+. 

+1)> 

(+> 

+,  >+l) 

and  they  describe  disjoint  subsets  of  Z  x  Z.  Let  us  call  the  above  set  of  29 
elements  for  AB  (for  Array  Bound);  then  CssR'P^Sign  x  Sign  x  Range)]  is 
isomorphic  to  T*(AB). 

To  conclude  the  development  of  the  complete  lattice  and  the  associated  Ga¬ 
lois  connection  for  the  Array  Bound  Analysis  we  shall  simply  construct  the 
reduced  tensor  product  of  the  Galois  connections  of  Examples  4.35  and  4.33. 
This  will  yield  a  Galois  insertion  isomorphic  to 

(V[Z  x  Z),0!ssr',7ssr',?7(AB)) 

Note  that  from  an  implementation  point  of  view  the  last  step  of  the  con¬ 
struction  has  paid  off:  if  we  had  stopped  with  the  direct  tensor  product  in 
Example  4.38  then  the  properties  would  need  45  bits  for  their  representation 
whereas  now  29  bits  suffice. 

Summary.  The  Array  Bound  Analysis  has  been  designed  from  three  simple 
Galois  connections  specified  by  extraction  functions: 

(i)  an  analysis  approximating  integers  by  their  sign  (Example  4.21), 

(ii)  an  analysis  approximating  pairs  of  integers  by  their  difference  in  mag¬ 
nitude  (Example  4.33),  and 

(iii)  an  analysis  approximating  integers  by  their  closeness  to  0,  1  and  —1 
(Example  4.33). 

We  have  illustrated  different  ways  of  combining  these  analyses: 

(iv)  the  relational  product  of  analysis  (i)  with  itself, 

(v)  the  functional  composition  of  analysis  (ii)  and  (iii),  and 

(vi)  the  reduced  tensor  product  of  analysis  (iv)  and  (v). 

It  is  worth  noting  that  because  the  resulting  complete  lattice  F(AB)  is  a 
powerset  then  it  is  indeed  possible  to  obtain  the  very  same  Galois  insertion 
using  an  extraction  function  twosignsrange' :  Z  x  Z  — »  AB.  ■ 
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We  shall  now  show  that  Galois  connections  are  indeed  useful  for  transforming 
computations  into  more  approximate  computations  that  have  better  time-, 
space-,  or  termination  behaviour.  We  can  do  so  in  two  different  ways.  In 
both  cases  we  assume  that  we  have  an  analysis  using  the  complete  lattice  L 
and  that  we  have  a  Galois  connection  ( L,a,j,M ). 

One  possibility  is  to  replace  the  analysis  using  L  with  an  analysis  using  M. 
In  Subsection  4.5.1  we  shall  show  that  if  the  analysis  using  M  is  an  upper 
approximation  to  the  analysis  induced  from  L  then  the  correctness  properties 
are  preserved.  We  shall  illustrate  this  approach  in  Subsection  4.5.2  for  the 
Monotone  Frameworks  considered  in  Chapter  2. 

An  alternative  is  only  to  use  the  complete  lattice  M  for  approximating  the 
fixed  point  computations  in  L.  So  rather  than  performing  all  computations 
on  the  more  approximate  lattice  M  the  idea  is  only  to  use  M  to  ensure  con¬ 
vergence  of  fixed  point  computations  and  not  needlessly  reduce  the  precision 
of  all  other  operations.  We  shall  illustrate  this  in  Subsection  4.5.3. 


4.5.1  Inducing  along  the  Abstraction  Function 


Now  suppose  that  we  have  Galois  connections  (Lj,aj,7i,  Mi)  such  that  each 
is  a  more  approximate  version  of  Li  (for  i  =  1,2).  One  way  to  make  use 
of  this  is  to  replace  an  existing  analysis  fp  :  L\  ->  Li  with  a  new  and  more 
approximate  analysis  gp:  M\  Mi.  We  already  saw  in  Section  4.4  that 


£*2  o  fp  o  7!  is  a  candidate  for  gp 

(just  as  72  o  gp  o  «i  would  be  a  candidate  for  fp).  The  analysis  a2  0  fP  °  7i  is 
said  to  be  induced  by  fp  and  the  two  Galois  connections.  This  is  illustrated 
by  the  diagram: 

fp 

L\  - *■  Li 


7i 


£*2 


M\ - Mi 

0-2  o  fp  O  71 


Example  4.40  Let  us  return  to  Example  4.9  where  we  studied  the  simple 
program  plus  and  specified  the  very  precise  analysis 

fplus(ZZ)  =  {zi  +  zi  |  (zi,zi)  €  ZZ} 
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using  the  complete  lattices  (V(Z),  C)  and  (V{Z  x  Z),C).  In  Example  4.21 
we  introduced  the  Galois  connection 


(HZ),  oSign ,  7sign  i  T’(Sign)) 

for  approximating  sets  of  integers  by  sets  of  signs.  In  Example  4.35  we  used 
the  relational  method  to  get  the  Galois  connection 

(V(Z  x  Z),ass',7ss',T’(Sign  x  Sign)) 


operating  on  pairs  of  integers.  We  now  want  to  induce  a  more  approximate 
analysis  for  the  plus  program 

SP!us  :  T*(Sign  x  Sign)  -4  T’(Sign) 

from  the  existing  analysis  /pius.  To  do  so  we  take 

Pplus  =  <^sign  0  /plus  0  7SS' 

and  simply  calculate  (for  SS  C  Sign  x  Sign) 


9PUSS) 


<*sign  (/plu«(7SS'  (SS))) 

0!sign(/pius({(2i,22)  €  Z  x  Z  j  (sign (*i ), sign (z2))  e  SS})) 
aSign({2i  +  z2  I  Zi,Z2  €  Z,  (signal),  sign(z2))  G  SS}) 
(sign(^i  +  z2)  \zi,z2eZ,  (signal ),sign(z2))  G  SS} 


=  O  ®  S2  I  (Slr?2)  e  ‘SS} 

where  ®  :  Sign  x  Sign  -4  T’(Sign)  is  the  “addition”  operator  on  signs  (so 
e.g. +0+ =  {+}  and +0- =  {-,0,+}).  ■ 


The  mundane  approach  to  correctness.  We  shall  now  follow 
the  approach  of  Section  4.1  and  show  that  correctness  of  fp  carries  over  to 
gp.  For  this  assume  that: 

Ri  :  Vi  x  Li~>  {true, false}  is  generated  by  Si  :  Vi  -4  Li 
The  correctness  of  the  analysis  fp  :  Li  -4  L2  is  then  expressed  by 

(p  h  •  •)  (J?!  -4  R2)  fp 

where  Ri  -4  R2  is  generated  by  Si  S2  (Lemma  4.8).  As  argued  in  Section 
4.3  we  get  a  correctness  relation  S,  for  V)  and  Mi  by  letting 

Si  :  Vi  x  Mi  -4  {true,  false}  be  generated  by  aj  o  Si  ■  Vi  -4  Mi 

which  is  equivalent  to  saying  that  Vi  Si  m,i  Vi  Ri  (7 i(nrii)).  The  correctness 
relation  for  the  analysis  using  M\  and  M2  will  be  5 1  —4  S2  which  will  be 
generated  by  (cq  o  Si)  -4  (a2  o/?2)  (Lemma  4.8).  We  now  have  the  following 
useful  result: 
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Lemma  4.41  If  (Li,  an,  ji,  Mp  axe  Galois  connections,  and  pt  :  Vi  ->  Li 
are  representation  functions  then 

((<*1  0  Pi)  -*  (<* 2  0  Pi))^)  =  ot2o  ((fii  /?2)(~0)  0  7i 

holds  for  all  ■ 

Proof  To  see  this  we  simply  calculate 

((aioJ81)-»(a2oft))H(mi)  =  |_J{a2(/32(u2))  |  ai(/?i(ui))  C  mi  Aui u2} 

=  <*2(|_|{/32(u2)  |  Pi(vi)  C  7i(mi  )  A  Vi  tl2}) 
=  a2((/3i-»/32)H)(7i(mi))) 

and  the  result  follows.  ■ 


We  shall  now  show  that  Lemma  4.41  yields: 

(p  h  •  •)  (Ri  -»  R2)  fp  A  a2  O  fpOjiQgp  =>•  (p  h  •  •)  (Si  -#■  S2)  gP 

This  just  means  that  if  fp  is  correct  and  if  gp  is  an  upper  approximation  to 
the  induced  analysis  then  also  gp  is  correct.  So  suppose  that 

(p  I-  •  •)  (i?i  -#•  R2)  fp 

and  that  a2  o  fp Qgp.  Since  (Li,  on,  7i,  Mi)  are  Galois  connections  and  fp 
and  gp  are  monotone  we  get  fp  C  72  °  gP°cn  as  illustrated  in  the  diagrams: 

fp  fp 


Li  - -  L2 


7i 

Mj 


|«2 

in 

m2 


Li 

<*i 


l2 

in 


Mx 


m2 


9p 


9p 


It  follows  that  (pi  -»  P2)(p  h  •  •)  E  72  o  gP  °  a  1  and  hence 

a2  o  (/?!  -*  p2)(p  h  •  •)  o  7j  C  gp 

By  Lemma  4.41  this  is  the  desired  result. 

We  shall  say  that  a  function  fp  :  Li  -t  L2  is  optimal  for  the  program  p  if 
and  only  if  correctness  of  a  function  /'  :  Li  — »  L2  amounts  to  fv  C  /'.  An 
equivalent  formulation  is  that  fp  is  optimal  if  and  only  if 

(Pi  -»  Pi)(p  I - -*■)  =  fP 

Lemma  4.41  may  then  be  read  as  saying  that  if  fp  :  L\  -»  L2  is  optimal  then 
so  is  a2  °  /p  o  71  :  Mi  ->  M2. 
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Fixed  points  in  the  induced  analysis.  Let  us  next  consider  the 
situation  where  the  analysis  fp  :  L\  -7  L2  requires  the  computation  of  the 
least  fixed  point  of  a  monotone  function  F  :  (L\  — >  L2)  — >  (L\  ->  L2)  so 
that  fp  =  lfp(F).  The  Galois  connections  (Li,  ati,^,  Mi)  give  rise  to  a  Galois 
connection  (Li  ->  L2,a,7,  Mi  — >  M2)  between  the  monotone  function  spaces 
as  shown  in  Section  4.4.  We  can  now  apply  our  technique  of  inducing  and 
let  G  :  (Mi  -*•  M2)  — >  (Mi  ->  M2)  be  an  upper  approximation  to  a  o  F  o  7. 
It  will  be  natural  to  take  gp  :  M\  ->•  M2  to  be  gp  =  lfp(G).  That  correctness 
of  /p  carries  over  to  <?p  follows  from  the  following  general  result: 

Lemma  4.42  Assume  that  (L,  a,  7,  M)  is  a  Galois  connection  and  let  /  : 
L  -»  L  and  g  :  M  ->  M  be  monotone  functions  satisfying  that  g  is  an  upper 
approximation  to  the  function  induced  by  /,  i.e.: 

a o f 07  C  g 


Then  for  all  m  €  M: 


g(m)  C  m  =>  f( 'y(m))  C  7(771) 

and  furthermore  lfp(f)  Q  7 (lfp(g))  and  a(lfp(f))  C  lfp(g)-  ■ 

Proof  First  assume  g(m)  C  m.  The  assumption  00/07^5  gives  a(f('i(m)))  C 
g(m)  and  hence  a(f('y(m)))  C  m.  Using  that  a  Galois  connection  is  an  adjunction 
(Proposition  4.20)  we  get  f('y(m))  £7(01)  as  required. 

To  prove  the  second  result  we  observe  that  (7(771)  |  g(m)  C  m}  C  {/  |  f(l)  C  1} 
follows  from  the  previous  result.  Hence  we  get  (using  Lemma  4.22): 

7<r>  1  = nw«)  1 9(m>  - -  r\n  1  -  0 

Using  Tarski’s  Theorem  (Proposition  A.  10)  twice  we  have  Ifp(g)  =  Recl(g)  = 
f1(m  I  s(m)  E  771)  and  lfp(f)  =  |lRed(/)  =  f|{I  I  f(l)  E  0  so  it  follows  that 
y(ltp(g))  3  lfp(f)  as  required.  Then  a(lfp(f))  C  Ifp(g)  follows  because  a  Galois 
connection  is  an  adjunction.  ■ 


4.5.2  Application  to  Data  Flow  Analysis 

Generalised  Monotone  Frameworks.  To  illustrate  how  these 
techniques  can  be  applied  we  shall  now  consider  a  generalisation  of  the  Mono¬ 
tone  Frameworks  of  Section  2.3.  So  let  a  generalised  Monotone  Framework 
consist  of: 

•  a  complete  lattice  L  =  (L,  C). 

Here  we  do  not  demand  that  L  satisfies  the  Ascending  Chain  Condition  and 
we  do  not  specify  the  space  T  of  transfer  functions  as  we  shall  be  taking 
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T  to  be  the  entire  space  of  monotone  functions  from  L  to  L  (which  clearly 
contains  the  identity  function  and  is  closed  under  composition  of  functions). 

An  instance  A  of  a  generalised  Monotone  Framework  then  consists  of: 

•  the  complete  lattice,  L,  of  the  framework; 

•  a  finite  flow,  F  C  Lab  x  Lab; 

•  a  finite  set  of  extremal  labels,  E  C  Lab; 

•  an  extremal  value,  t  6  L;  and 

•  a  mapping,  /.,  from  the  labels  Lab  of  F  and  E  to  monotone  transfer 
functions  from  L  to  L. 

As  in  Chapter  2  this  gives  rise  to  a  set  A-  of  constraints 
Ao(()  □  □{A.(OI(^V)€F}u4  where  4  =  1^ 

A.{i)  □  ft{A0{i)) 

where  t  ranges  over  the  labels  Lab  of  F  and  E.  We  write  (AOJA.)  f=  A- 
whenever  A0,  A.  :  Lab  ->  L  is  a  solution  to  the  constraints  A-.  It  is  useful 
to  consider  the  associated  monotone  function 

/ :  (Lab  ->  L)  x  (Lab  -4\L)  -►  (Lab  -)•  L)  x  (Lab  -►  L) 

defined  by: 

/(A0,  A.)  =  (  Al[_|{A.(£')  |  (i'J)  €  F}  U  4  ,  A Lft{A0{l))  ) 

We  then  have  the  following  important  result  (in  the  manner  of  Section  4.4): 
(A0,A.)  □  /(A0,  A.)  is  equivalent  to  (A0,  A.)  f=  A- 

Galois  connections  and  Monotone  Frameworks.  Let  now 
(L,  a,  7,  M)  be  a  Galois  connection  and  consider  an  instance  B  of  the  gener¬ 
alised  Monotone  Framework  M  that  satisfies 

•  the  mapping  g .  from  the  labels  Lab  of  F  and  E  to  monotone  transfer 
functions  of  M  -»  M  satisfies  gi  □  a  o  ft  o  7  for  all  l\  and 

•  the  extremal  value  j  satisfies  j  □  a(t) 

and  otherwise  B  is  as  A,  i.e.  has  the  same  F  and  E. 

As  above  we  get  a  set  of  constraints  B-  and  we  write  (B0,B,)  [=  B-  when¬ 
ever  B0,B ,  :  Lab  -4  M  is  a  solution  to  the  constraints.  The  alternative 
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formulation  is  ( B0 ,  B,)  □  g(B0,  B,)  where  g  :  (Lab  ->  M)  x  (Lab  ->  M)  -> 
(Lab  — >  M)  x  (Lab  ->  M)  is  the  monotone  function  associated  with  the 
constraints. 

We  shall  now  see  that  whenever  we  have  a  solution  to  the  constraints  obtained 
from  B  then  we  also  have  a  solution  to  the  constraints  obtained  from  A.  This 
can  be  expressed  by: 

(B0,  Bt)  [=  B-  implies  (7  o  B0, 7  o  £.)  j=  A- 


We  can  give  a  direct  (“concrete”)  proof  of  this  result  but  it  is  instructive  to 
see  how  it  follows  from  the  general  (“abstract”)  results  established  earlier. 
The  idea  is  to  “lift”  the  Galois  connection  ( L ,  a,  7,  M)  to  a  Galois  connection 

((Lab  ->  L)  x  (Lab  -4  L),a',  7',  (Lab  ->•  M)  x  (Lab  -4  M )) 

using  the  techniques  for  total  function  spaces  and  the  independent  attribute 
method  presented  in  Section  4.4.  The  assumptions  gt  □  a  o  ft  o  7  (for  all  i) 
and  j  □  a(t)  can  then  be  used  to  establish 

jDft'0/071 


as  the  following  calculations  show 

(a1  o/o7')(B0,J5.)  =  (. \e.l\{a('r(B.(l')))\(e',£)<EF}Ua(LtE ), 

Afcflr(/4(7(Bo(0)))) 

C  g(B0,Bm) 

where  we  have  used  Lemma  4.22.  We  can  now  use  Lemma  4.42  to  obtain 

g(B0,B.)  C  (B0,B,)  implies  f(j'(B0,B,))  C  7 '(B0,B,) 

and  it  follows  that  if  (B0,B,)  (=  B3  then  (7  o  JB0,7  0  B,)  |=  A-  as  stated 
above. 


The  mundane  approach  to  correctness.  The  above  result  shows 
that  any  solution  to  the  constraints  obtained  for  B  also  is  a  solution  to  the 
constraints  obtained  from  A.  We  shall  now  show  that  semantic  correctness  of 
A  implies  semantic  correctness  of  B. 

Let  us  reconsider  the  approach  taken  to  semantic  correctness  in  Section  4.1; 
here  F  =  Bow(Sir)  and  E  =  {init(5*)}.  For  the  analysis  A  this  calls  for  using 
a  representation  function 

(3  :  State  — ►  L 

and  the  correctness  of  all  solutions  to  A-  then  amounts  to  the  claim: 


Assume  that  (A0,  A,)  |=  A^  and  (5*,<ti)  — >*  cr2 ; 
then  /3(<ti)  Q  1  implies  /3(cr2)  C  I  ^  €  final(5*)}. 


(4.11) 
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For  the  analysis  B  it  follows  from  Section  4.3  that  it  is  natural  to  use  the 
representation  function 

ao  (3  :  State  ->  M 

and  the  correctness  of  all  solutions  to  B-  then  amounts  to  the  claim: 

Assume  that  ( B0,B .)  \=  B-  and  (S*,cri)  ->*  cr2;  ,  . 

then  (a  o  (3)(ai)  C  j  implies  (a  o  /3)(cr2)  C  |_|  {£.(£)  1 1  6  final(S*)}.  ' 

We  know  that  B  is  an  upper  approximation  of  the  analysis  induced  from  A 
and  shall  now  prove  that  (4.11)  implies  (4.12).  To  do  so  we  shall  need  to 
strengthen  the  relationship  between  the  extremal  values  of  A  and  B  and  we 

assume  that  j  satisfies  y(j)  =  i 

from  which  j  □  a(t)  readily  follows.  For  the  proof  that  (4.11)  implies  (4.12) 
suppose  that: 


( B0,B .)  (=  B3,  (5*,<ti)  -4*  02  and  ( ao/3)(ai )  Cj 


It  follows  that: 

(7  o  Bo,')  °  B,)  )=  A3,  (5*,ct  1)  -»*ct2  and  E 

From  (4.11)  we  get  /?(a-2)  Q  U{7  0  B.{()  |  l  €  final(5*)}  and  hence  ^(c2)  C 
7(UW*)  I  l  €  hnai(5*)})  showing  the  desired  (a  o  /3)(<t2)  C  U{^*(^)  I  ^  G 
finai(5*)}. 

A  Worked  Example 

As  a  concrete  example  we  shall  now  consider  an  analysis  SS  for  the  While 
language  that  approximates  how  sets  of  states  are  transformed  into  sets  of 
states.  First  we  prove  that  it  is  correct.  Then  we  show  that  the  Constant 
Propagation  Analysis  of  Section  2.3  is  an  upper  approximation  of  an  analysis 
induced  from  SS.  This  will  then  establish  the  correctness  of  the  Constant 
Propagation  Analysis. 

Sets  of  states  analysis.  The  analysis  SS  approximating  the  sets  of 
states  will  be  a  generalised  Monotone  FYamework  with: 

•  the  complete  lattice  ('P(State),  C). 

Given  a  label  consistent  statement  5*  in  Stmt  we  can  now  specify  the  in¬ 
stance  as  follows: 


the  flow  F  is  fiow(5*); 
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•  the  set  E  of  extremal  labels  is  {init(S*)}; 

•  the  extremal  value  l  is  State;  and 

•  the  transfer  functions  are  given  by  /ss: 

ffs( S)  =  {a[x  i-4  .4[a]cr]  |  a  €  E}  if  [x  :=  a]*  is  in  S* 

ffs(E)  —  £  if  [skip]*  is  in  5* 

/P(E)  =  £  if  [6]' is  in  5* 

where  E  C  State. 

Correctness.  The  following  result  shows  that  this  analysis  is  correct  in 
the  sense  explained  above: 

Lemma  4.43  Assume  that  (SS0,SS.)  (=  SS-  and  (S*,cti)  -4*  <72;  then 
o  1  e  State  implies  01  €  (J{SS.(f)  1 1  £  fina  1(5*)}.  ■ 

Proof  Prom  Section  2.2  we  have: 

(5,  <r)  -4  (S'.cr')  implies  final(S)  3  final(S')  A  Sow(S)  2  How(S') 

and  as  in  Chapter  2  it  is  immediate  that 

flow(S)  D  aow(S')  A  (SSo.SS.)  |=  SS~(S)  implies  (SS0,SS.)  (=  SS2(S') 

It  then  suffices  to  show 

(SSo.SS.)  f=  SS2(S)  A  (S.cr)  -iff'AffG  SS0(init(S)) 
implies  cr'  €  U{SS.(f)  |  f  6  Gnal(S)} 

(SSo.SS.)  (=  SS2(S)  A  (S.cr)  -4  {S'.cr')  A  <7  €  SS0(init(S)) 
implies  <7'  €  SS0(init(S')) 

since  then  an  induction  on  the  length  of  the  derivation  sequence  (S*.  <7i)  -4*  cr2  will 
give  the  result.  The  proof  proceeds  by  induction  on  the  inference  in  the  semantics. 
We  only  consider  a  few  of  the  interesting  cases. 

The  case  ([x  :=  a]*,  a)  — >  a[x  t-4  A[a]a].  Then  SS-  (S)  will  contain  the  equation 
SS.(f)  D  {a[x  »-4  A[a\a]  \  a  G  SS0(£)} 

and  since  init([x  :=  a]*)  =  £  and  fina/([x  :=  a]*)  =  {£}  we  see  that  that  the  required 
relationship  holds:  if  cr  €  SS0(£)  then  cr[x  r4  A[a](r]  G  SS,(£). 

The  case  (Si;S2,<r)  -4  (S[ ;  S2,  cr')  because  (Si,  cr)  -4  (S'i,cr').  Prom  the  assumption 
a  G  SS0(init(Si;  S2))  we  get  cr  €  SS0(init(Si ))  and  the  induction  hypothesis  gives 
cr'  G  SS0(init(S[)).  But  then  cr'  G  SS0(init(S[;  S2))  as  required. 

The  case  (Si;S2,cr)  -4  (S2,er')  because  (Si.cr)  — >■  cr'.  Prom  the  assumption  a  6 
SS0(init(Si  \  S2))  we  get  cr  €  SSa(init(Si ))  and  the  induction  hypothesis  gives  a'  G 
IJ  {SS.  (t)  1 1  G  final(Si ) } .  We  have 

{(f,init(S2))  1 1  €  final(Si)}  C  flow(Si;S2) 
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and  since  we  have  the  constraints 

ss0(£)  d  (J{ss.(0  |  (t,e)  e  flow(si;s2)} 

for  all  £  we  get 

SS0(init(Si))  D  (J{SS,(£)  |  £  €  final(Si)} 
and  hence  a  £  SS0(init(S2))  as  required. 

The  remaining  cases  follow  the  same  pattern  and  are  omitted.  ■ 

Remark.  The  SS  analysis  is  unlikely  to  be  optimal  and  hence  is  unlikely  to 
equal  the  collecting  semantics  (see  Exercise  4.5).  This  may  be  demonstrated 
by  exhibiting  an  example  where  (J{SS.(£)  I  ^  £  fina/(S*)}  is  strictly  larger 
than  {a1  |  (5*,  a)  ->*  a'  A  a  £  State}  and  it  is  fairly  easy  to  do  so.  To  obtain 
a  specification  of  the  collecting  semantics  we  should  let  transfer  functions  be 
associated  with  edges  rather  than  nodes  as  this  would  allow  us  to  record  the 
outcome  of  tests  (see  Exercise  2.11).  ■ 

Constant  Propagation  Analysis.  The  analysis  of  Section  2.3  is 
specified  by  a  generalised  Monotone  Framework  consisting  of 

•  the  complete  lattice  Statecp  =  ((Var  -4  ZT)±,  C). 

The  instance  for  the  statement  5*  is  determined  by 

•  the  flow  F  is  flow(5*); 

•  the  set  E  of  extremal  labels  is  (init(5*)}; 

•  the  extremal  value  i  is  Xx.T ;  and 

•  the  transfer  functions  are  given  by  the  mapping  /cp  defined  in  Table 
2.7. 

Galois  connection.  The  relationship  between  the  two  analyses  is  es¬ 
tablished  by  defining  the  representation  function 

Pcp  ■  State  -4  Statecp 

by  Pcp{c)  =  o  (as  in  Example  4.7).  As  in  Section  4.3  this  gives  rise  to  a  Galois 
connection  ('P(State),a'cp>7cp, Statecp)  where  acp(E)  =  \_\{(3cp(ct)  \  a  € 
£}  and  7cp(ct)  =  {a  \  Pcp{&)  E  <?}•  One  can  now  show  that  for  all  labels  £ 

f(P  3  «cp  °  ftS  ° 7cp 

as  well  as  7cp(Ax.T)  =  State.  Let  us  only  consider  the  case  where  [x  :=  a]* 
occurs  in  5*  and  calculate 
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=  acp({u[x  i-»  Alaja]  |  a  C  <?}) 

=  | _ |{cr[a:  A[a\a]  \  a  Ca} 

C  a[x  t-+  |_|{-4[a]cr  |  a  C  5}] 

E  ftP(Z) 

and  where  the  last  step  follows  from  |_j{^4£a,]cr  |  a  C  5}  C  Acp[a}a  which 
can  be  proved  by  a  straightforward  structural  induction  on  a. 

Thus  we  conclude  that  CP  is  an  upper  approximation  to  the  analysis  induced 
from  SS  by  the  Galois  connection  and  hence  it  is  correct. 

4.5.3  Inducing  along  the  Concretisation  Function 

Widening  operator  induced  by  Galois  connection.  Suppose 
that  we  have  a  Galois  connection  (L,  a,  7,  M)  between  the  complete  lattices 
L  and  M,  and  also  a  monotone  function  /  :  L  -4  L.  Often  the  motivation 
for  approximating  /  arises  because  a  fixed  point  of  /  is  desired,  and  the 
ascending  chain  (/n(X))n  does  not  eventually  stabilise  (or  may  do  so  in  too 
many  iterations).  Instead  of  using  aofo"/:M-+Mto  remedy  this  situation 
it  is  often  possible  to  consider  a  widening  operator  Vm  :  M  x  M  -4  M  and 
use  it  to  define  Vt  :  L  x  L  ->  L  by  the  formula: 

h  Vt  l2  ="y(o(li)  Vm  a(l2)) 

If  Vt  turns  out  to  be  a  widening  operator  we  then  know  how  to  approximate 
the  least  fixed  point  of  /  :  L  -»  L  while  calculating  over  L.  This  has  the 
advantage  that  the  coarser  structure  of  M  is  only  used  to  ensure  convergence 
and  does  not  needlessly  reduce  the  precision  of  all  other  operations.  The 
following  result  gives  sufficient  criteria  for  this  approach  to  work: 


Proposition  4.44 

Let  ( L , a, 7,  M)  be  a  Galois  connection  and  let  Vm  :  MxM  M 
be  an  upper  bound  operator.  Then  the  formula 

h  Vt  l2  =  7 (a(Zi)  Vm  a{h)) 

defines  an  upper  bound  operator  Vt  :  L  x  L  L.  It  defines 
a  widening  operator  if  one  of  the  following  two  conditions  are 
fulfilled: 

(i)  M  satisfies  the  Ascending  Chain  Condition,  or 

(ii)  (L,  a,  7,  M)  is  a  Galois  insertion  and  Vm  :  M  x  M  M  is 
a  widening  operator. 
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Proof  First  we  prove  that  Vl  is  an  upper  bound  operator.  Since  Vm  is  an  upper 
bound  operator  we  have  a(U)  C  a(/i) Vmo^).  Using  that  a  Galois  connection  is 
an  adjunction  we  get  U  C  7(a(Zi)VMa(Z2)),  i-e.  U  C  ZiVlZ2. 

Assume  now  that  condition  (i)  is  fulfilled  and  consider  an  ascending  chain  (Z„)n 
in  L.  We  know  that  also  (l„  )n  is  an  ascending  chain  and  that  lnL  €  7[M]  for 
n  >  0.  Hence  ( a(lnL))n  is  an  ascending  chain  and  since  M  satisfies  the  Ascending 
Chain  Condition  there  exists  no  >  1  such  that  a(lnL)  =  ct(ln, ^ )  for  all  n  >  no.  So 
7 (a(l^L))  =  7 (a(/no ))  for  all  n  >  no  and  using  that  70007  =  7  (Fact  4.24)  we 
get  lnL  =  In, a  for  all  n  >  no.  This  completes  the  proof. 

Assume  next  that  condition  (ii)  is  fulfilled  and  consider  again  an  ascending  chain 
(Z„)n  in  L.  Since  a  is  monotone  it  follows  that  (o(Z„)n)  is  an  ascending  chain  in  M. 
Now,  Vm  is  a  widening  operator  on  M  so  there  exists  no  such  that  (o(Z„))Vm  = 
(a(Zno))VM  for  n  ~  no .  We  shall  now  prove  that 

(a(fn))v“  =  a(l?)  (4.13) 

for  all  n  >  0.  The  case  n  =  0  is  immediate  since  (q(Zo))Vm  =  a(Zo)  =  <*« oL)-  ^r 
the  induction  step  we  assume  that  (a(Z„))Vw  =  a(Z„  ).  Then 

(a(Z„+i))VM  =  (a(Z„))v”  Vm  a(/.+i) 

=  a(l?)  Vm  a(l»+i) 

and 

=  a(lnL  V£  ln+1) 

=  oW^^VmoM)) 

=  a(Z^)  Vm  a(/«+i) 
since  (L,  0,7,  M)  is  a  Galois  insertion. 

Using  (4.13)  we  thus  have  that  there  exists  no  such  that  a(lJL )  =  a(/^ £)  for  all 
n  >  no-  But  then  7(a(Zni))  =  7(a(Zn£))  and  hence  for  all  n  >  n0 

because  (L,  o,  7,  M)  is  a  Galois  insertion.  This  completes  the  proof.  ■ 

Precision  of  induced  widening  operator.  The  following  result 
compares  the  precision  of  using  the  widening  operator  Vl  with  the  precision 
of  using  the  widening  operator  Vm- 

Lemma  4.45  If  (L,a,j,M)  is  a  Galois  insertion  such  that  7(J Im)  =  ±l, 
and  if  Vm  :  M  x  M  -»  M  is  a  widening  operator,  then  the  widening  operator 
Vl  :  L  x  L  — l  L  defined  by  l\  Vl  h  =  7(a(fi)  Vm  a(/2))  satisfies 

(/)  =  7 WPv*,  (a  0  /  0  7)) 

for  all  monotone  functions  /  :  L  L.  ■ 

Proof  By  Proposition  4.44  we  already  know  that  Vl  is  a  widening  operator.  Hence 
there  exists  n/  >  0  such  that  lfpVL{f)  =  =  /$L  for  all  n  >  n /.  Next  write 
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g  =  a  o  /  o  7  and  recall  that  Vm  is  a  widening  operator.  Hence  there  exists  ng  >  0 
such  that  WbvM  (p)  =  Pvm  =  PvM  for  all  n  >  ng .  To  obtain  the  desired  result  it 
therefore  suffices  to  prove 


fvL  =  7  (pvM)  (4.14) 

by  induction  on  n.  The  base  case  (n  =  0)  is  immediate  since  f^L  =  -Ll  and 
PvM  =  -L m  and  we  assumed  that  JLr,  =  7(±m). 

To  prepare  for  the  induction  step  we  prove  that  (4.14)  implies  that: 


/(/vJE/vl  p(PvM)EPvM  (4.15) 


For  “=>”  we  calculate  (using  (4.14)  and  that  (L,  a,  7,  M)  is  a  Galois  connection): 


/(/vJE/vt  => 


=> 

=> 


«(/(/vJ)  Ea(/vJ 

«(/(7(PvM)))  E  a(7(PvM)) 
P(pvM)  E  a(7(5vM)) 
p(pvL )  E  PvM 


For  “4=”  we  calculate  (using  (4.14)  and  that  (L,  a,  7,  M)  is  a  Galois  connection): 


p(pvm  )  E  PvM 


=>  7(p(Pvm))  E7(Pvm) 

=>  7(«(/(7(Pvm  ))))  E  7(pvM ) 
=>  7(a(/(/vJ))  E  /vt 
=>.'./(/vL)  E  /vL 


Returning  to  the  induction  step  (n  >  0)  of  the  proof  of  (4.14)  we  calculate: 


/vL 


if/(/vr)E/v“ 


fn~l 
JVL 

f^L  1  otherwise 

fn-l 

Jv, 


■{ 

■{ 

-{ 

=  7  (  {  afrfcfc 

=  7({f: 


ifp^-^EPv"1 


fvL  1  Vl  /(/vl  )  otherwise 
7(Sv«) 


ifp(pC)E»v- 


7(«(7(ffvM  ))  «(/(7(PvM  ))))  otherwise 

lf  9(9^)  E  PvM' 

vM  ))  Vm  p(9vm  )  otherwise 


if  P(PvMl)  E  Pv; 


Vm  )  otherwise 


n  —  1 
rM 


=  7(Pvm) 


In  this  calculation  we  have  used  that  (4.14)  and  (4.15)  hold  for  n  —  1,  the  definition 
of  Vc,  and  that  (L,  0,7,  M)  is  a  Galois  insertion.  .  ■ 


This  result  then  provides  the  formal  justification  for  the  motivating  remarks 
in  the  beginning  of  the  subsection.  To  be  specific  let  M  be  of  finite  height, 
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let  ( L,a,j,M )  be  a  Galois  insertion  satisfying  7(±m)  =  1  l,  and  let  V*f  be 
the  least  upper  bound  operator  U m-  Then  the  above  lemma  shows  that 

1{PvLU)  =  'r(lfp(aofoj)) 

which  means  that  (/)  equals  the  result  we  would  have  obtained  if  we 
decided  to  work  with  Q0/07  :  M  ->  M  instead  of  the  given  /  :  L  ->  L; 
furthermore  the  number  of  iterations  needed  turn  out  to  be  the  same.  Since 
the  greater  precision  of  L  over  M  is  available  for  all  other  operations,  this 
suggests  that  the  use  of  widening  operators  is  often  preferable  to  the  approach 
of  Subsection  4.5.1. 


Concluding  Remarks 

In  this  chapter  we  have  only  been  able  to  touch  upon  a  few  of  the  central 
concepts  of  Abstract  Interpretation:  this  has  mainly  been  based  on  [27, 29,  25] 
and  [30]  while  the  series  of  examples  leading  up  to  Example  4.39  are  based 
on  [140].  Much  more  can  be  said  both  about  the  development  of  the  theory 
and  about  its  applications.  In  this  section  we  briefly  discuss  some  of  the  more 
important  concepts  that  have  been  omitted  so  far. 

Upper  closure  operators..  An  upper  closure  operator  p  :  L  -*  L  is 
a  monotone  function  that  is  extensive  (i.e.  satisfies  p  □  A  1.1)  and  idempotent 
(i.e.  pop  =  p).  Such  operators  arise  naturally  in  Abstract  Interpretation  [29] 
because  whenever  (L,  a,  7,  M)  is  a  Galois  connection  the  function  70 a  :  L  -> 
L  is  easily  seen  to  be  an  upper  closure  operator.  Furthermore,  if  p  :  L  -►  L 
is  an  upper  closure  operator  then  the  image  p[L ]  =  {p(l)  \  l  6  L}  of  L  under 
p  equals  the  set  Fix(p)  =  {l  €  L  \  l  =  p(l)}  of  fixed  points  of  p  and  is  a 
complete  lattice  under  the  partial  ordering  of  L\  in  fact  (L,p,Xl.l,p[L])  is  a 
Galois  insertion. 

It  follows  that  upper  closure  operators  may  be  used  to  represent  Galois  con¬ 
nections  by  simply  demanding  that  the  more  approximate  space  M  is  actually 
a  subset  of  L  and  that  no  essential  features  are  lost  by  doing  this.  This  then 
opens  up  for  directly  comparing  the  precision  of  various  Galois  connections 
over  the  same  complete  lattice  L  by  simply  relating  the  closure  operators. 
The  relation  pi  C  p2  is  naturally  defined  by  VI  e  L  :  p\  ( l )  C  p2  ( l )  but  turns 
out  to  be  equivalent  to  the  condition  that  P2(L)  C  pi(L)  and  represents  the 
fact  that  p2  is  more  approximate  than  p\. 

Having  defined  an  ordering  on  the  set  of  upper  closure  operators  on  L  one 
can  next  show  that  it  is  itself  a  complete  lattice:  the  least  element  is  given 
by  the  upper  closure  operator  A l.l  and  the  greatest  element  by  ALT.  The 
binary  greatest  lower  bound  operator  fl  is  of  special  interest:  it  gives  rise  to 
the  construction  of  the  reduced  product  [29]  as  we  saw  it  in  Section  4.3. 
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A  number  of  additional  constructs  can  be  explained  by  means  of  upper  clo¬ 
sure  operators:  we  just  mention  reduced  cardinal  power  [29]  and  disjunctive 
completion  [29].  By  “inverting”  some  of  these  constructions  it  may  then  be 
possible  to  find  the  “optimal  bases”  with  respect  to  a  given  combination:  for 
reduced  product  the  notion  of  pseudo-complementation  has  been  used  to  find 
the  minimal  factors  [23,  24],  and  for  disjunctive  completion  one  can  identify 
the  basic  irreducible  properties  that  are  inherently  necessary  for  the  analysis 
[47,  48]. 

Stronger  properties  on  the  complete  lattices.  Being  a  com¬ 
plete  lattice  is  a  rather  weak  notion  compared  to  being  a  powerset.  By 
considering  more  structure  on  the  complete  lattices,  say  distributivity,  and 
identifying  the  elements  that  correspond  to  singletons,  e.g.  atoms  or  join  irre¬ 
ducible  elements,  it  is  frequently  possible  to  lift  some  of  the  stronger  results 
that  hold  for  powersets  to  a  larger  class  of  complete  lattices. 

Since  powersets  are  isomorphic  to  bit  vectors  this  gives  a  way  of  finding  more 
general  conditions  on  analyses  for  when  they  are  as  efficient  as  the  Bit  Vector 
Frameworks.  This  is  of  particular  interest  in  the  case  of  fixed  points,  where 
one  can  use  properties  of  distributive  lattices  and  distributive  analyses  to 
give  rather  low  bounds  on  the  number  of  iterations  needed  for  the  ascending 
chain  (/n(±))n  to  stabilise  [99,  90]. 

Another  line  of  work  concerns  the  development  of  the  tensor  product  for 
complete  lattices  that  are  not  also  powersets  [83,  85,  87].  Several  notions  of 
tensor  product  have  been  studied  in  lattice  theory  but  the  development  of 
tensor  products  suitable  for  program  analysis  was  first  done  in  [83]. 

Concrete  analyses.  In  this  chapter  we  have  concentrated  on  introduc¬ 
ing  some  of  the  key  notions  in  the  theory  of  Abstract  Interpretation  and  only 
occasionally  have  we  hinted  at  concrete  applications. 

One  of  the  main  applications  of  Abstract  Interpretation  has  been  in  the  area 
of  logic  programming.  To  implement  a  program  efficiently  it  is  important  to 
have  precise  information  about  the  substitutions  that  may  reach  the  various 
program  points;  a  central  question  to  be  asked  for  a  substitution  is  whether  or 
not  it  is  ground.  A  number  of  analyses  have  been  designed  for  this  and  most 
of  these  build  upon  the  framework  of  Abstract  Interpretation.  This  includes 
the  design  of  iteration  strategies  based  on  widening,  and  the  decomposition 
of  base  domains  using  the  techniques  mentioned  above  under  upper  closure 
operators. 

Another  main  application  of  Abstract  Interpretation  has  been  to  approxi¬ 
mate  subsets  of  n-dimensional  vector  spaces  over  integers  or  rationals.  For 
the  purpose  of  this  discussion  we  shall  limit  ourselves  to  at  most  two  di¬ 
mensions  (the  line  and  the  plane).  In  the  case  of  one  dimension  there  are 
two  main  techniques.  One  we  already  illustrated:  the  lattice  of  intervals, 
and  it  may  be  generalised  to  consider  (possibly  finite)  unions  of  intervals. 
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The  other  technique  records  sets  of  numbers  modulo  some  base  value,  e.g. 
{x  |  x  mod  ki  =  k2}.  Clearly  these  two  analyses  can  be  combined.  In  the  case 
of  two  (or  more)  dimensions  it  is  straightforward  to  perform  an  independent 
attribute  analysis  where  the  techniques  above  are  applied  component-wise 
for  each  dimension. 

A  large  effort  has  been  conducted  to  develop  more  interesting  relational  analy¬ 
ses  for  two  (or  more)  dimensions  where  the  choice  of  axes  is  of  less  importance 
for  the  ability  to  approximate  subsets  of  vector  space.  An  early  method  was 
the  affine  subspaces  of  Karr  [71]  where  sets  of  the  form  {(x,y)  |  kix  +  k2y  = 
fc3)  can  be  described.  The  generalisation  from  equality  to  inequality,  and 
allowing  to  take  intersections  of  such  subsets,  was  considered  by  Cousot  and 
Halbwachs  [31]  and  resulted  in  a  study  of  convex  polygons.  Generalisations 
and  combinations  of  these  ideas  have  been  developed  by  Granger  [50,  51]  and 
by  Masdupuy  [79]. 

An  interesting  line  of  work  pioneered  by  Deutsch  [34,  35]  is  to  change  the 
problem  of  describing  regular  sets  of  words  over  a  finite  alphabet  to  the 
problem  of  describing  sets  of  integer  vectors.  This  is  by  no  means  trivial  but 
once  it  has  been  achieved  it  opens  up  for  using  all  of  the  above  techniques  to 
represent  also  regular  sets  of  words.  This  is  very  important  for  the  analysis  of 
higher-order  and  concurrent  programs,  as  shown  by  Deutsch  and  Colby  [21, 
22],  since  it  can  describe  the  shape  of  activation  records  and  communication 
patterns  in  much  greater  precision  than  other  comparative  techniques. 

We  should  also  mention  techniques  for  building  the  abstract  space  of  prop¬ 
erties  “dynamically”  [16]  and  for  using  widening  and  narrowing  to  improve 
the  performance  of  chaotic  iteration  [17]. 

Duality.  The  dual  Cd  of  a  partial  ordering  C  is  obtained  by  defining 
li  Cd  Z2  if  and  only  if  l2  C  h;  thus  we  could  write  Cd  as  □  .  Any  concept 
defined  in  terms  of  partial  orderings  can  be  dualised  by  replacing  all  partial 
orderings  by  their  dual.  In  this  way  the  dual  least  element  is  the  greatest 
element,  and  the  dual  least  upper  bound  is  the  greatest  lower  bound  etc.  The 
principle  of  lattice  duality  of  Lattice  Theory  says  that  if  any  statement  about 
partially  ordered  sets  is  true  then  so  is  the  dual  statement.  (Interestingly  the 
concept  of  monotonicity  is  its  own  dual.)  However,  we  should  like  to  point 
out  that  the  dual  of  a  complete  lattice  may  of  course  differ  from  the  complete 
lattice  itself;  pictorially  we  represent  this  by  drawing  the  complete  lattice 
“up-side  down” . 

The  principle  of  lattice  duality  is  important  for  program  analysis  because  it 
gives  an  easy  way  of  relating  the  literature  on  Abstract  Interpretation  to  the 
“classical”  literature  on  Data  Flow  Analysis:  simply  dualise  the  complete 
lattices.  So  in  Abstract  Interpretation  the  greatest  element  is  trivially  safe 
and  conveys  no  information  whereas  in  “classical”  Data  Flow  Analysis  it  is 
the  least  element  that  has  this  role.  Similarly,  in  Abstract  Interpretation  we 
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axe  interested  in  least  fixed  points  whereas  in  “classical”  Data  Flow  Analysis 
we  are  interested  in  greatest  fixed  points. 

Staying  within  the  basic  approach  of  Abstract  Interpretation,  that  going  up 
in  the  complete  lattice  means  losing  information,  it  is  still  possible  to  dualise 
much  of  the  development:  in  particular  we  can  define  the  notion  of  dual  Ga¬ 
lois  connections.  To  see  why  this  may  be  worthwhile  consider  the  following 
scenario.  In  program  analysis  we  aim  at  establishing  an  element  It  €  L  for 
describing  the  set  of  values  that  may  reach  a  given  program  point  l.  In  pro¬ 
gram  transformation  it  is  frequently  the  case  that  a  certain  transformation 
E  is  valid  only  if  the  set  of  values  that  reach  a  certain  point  have  certain 
properties;  we  may  formulate  this  as  the  condition  It  C  Is-  Now  if  we  want 
to  be  more  approximate  we  approximate  It  to  l'e  and  to  l~  and  formulate 
the  approximate  condition  l't  C  /=.  To  ensure  that  l't  C  l~  implies  It  C  we 
demand  that  It  C  l't  and  that  14  C  h.  Thus  properties  of  program  points  are 
approximated  by  going  up  in  the  complete  lattice,  for  which  Galois  connec¬ 
tions  are  useful,  whereas  enabling  conditions  for  program  transformations  are 
approximated  by  going  down  in  the  complete  lattice,  and  for  this  the  concept 
of  dual  Galois  connections  is  useful. 

A  final  word  of  advice  concerns  the  interplay  between  Abstract  Interpretation 
and  Denotational  Semantics.  In  Denotational  Semantics  the  least  element 
conveys  absolutely  no  information,  and  we  learn  more  when  things  get  larger 
according  to  the  partial  order;  had  there  been  a  greatest  element  it  would 
have  denoted  conflicting  information.  This  is  quite  opposite  to  the  situation 
in  Abstract  Interpretation  where  the  greatest  element  conveys  absolutely  no 
information  and  we  learn  more  when  things  get  smaller  according  to  the  par¬ 
tial  order;  the  least  element  often  denotes  non-reachability.  Hence  it  would 
be  dangerous  to  simply  apply  too  many  of  the  intuitions  from  Denotational 
Semantics  when  performing  Abstract  Interpretation  not  least  because  both 
formalisms  ask  for  least  fixed  points  and  therefore  are  not  duals  of  one  an¬ 
other. 


Mini  Projects 

Mini  Project  4.1  A  Galois  Connection  for  Lists 

In  a  series  of  examples  leading  up  to  Example  4.39  we  constructed  a  Galois 
insertion  for  recording  the  relationship  between  pairs  of  integers;  it  was  given 
by 

(V(Z  x  Z),assR'i7ssE','P(AB)) 

where  AB  C  Sign  x  Sign  x  Range  contained  only  29  elements  (out  of  the 
45  possibilities). 
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In  this  mini  project  we  are  going  to  construct  a  Galois  insertion  for  recording 
the  relationship  between  pairs  of  lists.  Let  V  be  the  domain  of  lists  of  finite 
length  over  some  simple  data  type.  We  write  x  = ■  [xi ,  •  •  • ,  x„]  for  a  list  with 
n  elements  whose  first  element  is  *1;  when  n  =  0  we  write  x  —  [  ].  Next  let 
*  =  and  y  =  [j/i ,  •  •  • ,  ym]  be  two  lists  .  They  have  the  same  head 

if  and  only  if  n  >  0,  m  >  0  and  x\  =  yi .  The  list  x  is  a  suffix  of  y  if  and  only 
if  there  exists  k  >  0  such  that  n  +  k  =  m  and  X{  =  yi+*  for  i  €  {1,  •  •  ■  ,n}. 
Finally  we  write  length(x)  =  n  and  length(y)  =  m. 

The  Galois  insertion  should  have  the  form 

(V(VxV),a,rV(  LR)) 

where  LR  C  "P({H,  S})  x  Range.  Here  H  means  that  the  lists  have  the  same 
head,  S  means  that  the  shorter  list  is  a  suffix  of  the  other,  and  the  range 
components  describe  length(x)  -  length(y)  where  x  is  the  first  list  and  y  the 
second  list. 

Complete  the  details  of  the  specification.  ■ 

Mini  Project  4.2  Correctness  of  the  Shape  Analysis 

We  shall  now  return  to  the  Shape  Analysis  of  Section  2.6  and  show  how  it 
gives  rise  to  a  Galois  connection.  Recall  that  the  semantics  uses  configura¬ 
tions  with  a  state  a  €  State  and  a  heap  component  H  €  Heap  and  that  the 
analysis  works  on  shape  graphs  consisting  of  an  abstract  state  S,  an  abstract 
heap  H  and  a  sharing  component  is. 

We  shall  begin  by  defining  a  function  vars  that  given  a  location  and  a  state 
will  determine  the  associated  abstract  location: 

vars(£)(cr)  =  nx  where  X  =  {x  \  cr(x)  =  £} 

Proceed  as  follows: 

1.  Define  a  representation  function 

/?sa  :  State  x  Heap  'P(SG) 

that  to  each  state  and  heap  associates  a  singleton  set  with  a  compatible 
shape  graph  (as  defined  in  Section  2.6)  and  construct  the  associated 
Galois  connection 

CP(State  x  Heap), qSa, 7sai ^(SG)) 

Is  it  a  Galois  insertion? 

To  establish  the  correctness  of  the  analysis  we  shall  follow  the  approach  of 
Section  4.5.2: 


268 


ABSTRACT  INTERPRETATION 


2.  Specify  an  analysis  SH  approximating  the  sets  of  pairs  of  states  and 
heaps  as  a  generalised  Monotone  Framework  over  the  complete  lat¬ 
tice  (P(State  x  Heap),  C);  write  ffH  for  the  associated  transfer  func¬ 
tions.  Prove  the  correctness  of  the  analysis  SH  (i.e.  prove  an  analogue 
of  Lemma  4.43). 

3.  Show  that  ffA  □  asA  0  ffH  0  7sa  for  all  transfer  functions  and  conclude 
that  the  Shape  Analysis  is  correct.  Determine  whether  or  not  ffA  = 
<*sa  o  ffH  o  7sA  holds  for  all  transfer  functions.  (See  Exercise  2.22.)  B 

Mini  Project  4.3  Application  to  Control  Flow  Analysis 

In  this  mini  project  we  shall  perform  an  analogue  of  the  development  of 

Subsection  4.5.2  for  the  Control  and  Data  Flow  Analysis  of  Section  3.5. 

1.  Specify  a  “sets  of  values”  analysis 

(Csv,/5sv)  t=sv  e 

in  the  manner  of  Section  3.5.1  (by  taking  Data  =  Val  where  Val  is  as 
in  Section  3.2).  Formulate  and  prove  a  semantic  correctness  result  in 
the  manner  of  Example  4.40  and  Theorem  3.10. 

2.  Let  a  monotone  structure  ( L ,T)  be  given  as  in  Section  3.5.2  and  con¬ 
sider  a  Galois  connection  (T*(Val),a,7, L).  Motivated  by  the  judge¬ 
ments  of  the  acceptability  relation  (C,  D,  p,  d)  fyx?  e  construct  a  Galois 
connection: 


({(CsviPsv)  |  7', {(C, 6, p,d)  |  •••}) 

Formulate  and  prove  a  result  intended  to  establish 

(C,  D,  p,  d)\=De  =>  7,((C,  D,  p ,  d))  |=sv  e 

and  argue  that  this  shows  the  semantic  correctness  of  the  Control  and 
Data  Flow  Analysis.  H 


Exercises 

Exercise  4.1  For  the  complete  lattice  (Sign',  C)  of  Figure  4.10  define  a 
correctness  relation  Rzs1  ■  Z  x  Sign'  ->  {true,  false}.  Verify  that  it  indeed  has 
the  properties  (4.4)  and  (4.5).  Next  define  a  representation  function  fas'  : 
Z  -4  Sign'  and  show  that  the  Rzs'  constructed  above  is  indeed  generated  by 
Pzs1  ■  ■ 
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Figure  4.10:  The  complete  lattice  (Sign',  C). 


Exercise  4.2  Show  that  if  (4.4)  and  (4.5)  hold  for  R  and  L  then  we  also 
have: 

v  R  li  A  v  R  I2  =*•  v  R  (li  U  I2) 

and  more  generally: 

(VI  eL'  ^0:vRl)  =>  vR([]L') 

Give  an  example  showing  that  v  R  X  fails  even  though  (4.4)  and  (4.5)  are 
fulfilled.  ■ 

Exercise  4.3  Show  that  the  Control  Flow  Analysis  of  Chapter  3  is  indeed 
correct  in  the  sense  of  condition  (4.3)  as  claimed  in  Example  4.4.  To  do  so 
first  show  that 

(C,  p)  \=v*  iff  v  V  (p,  C(C)) 

whenever  v  is  a  value  (i.e.  a  closure  or  a  constant) .  Next  show  that 

[  ]  H  (e*  vi')‘  -4*  A  (C ,p)  |=  (e*  v*')*  =►  (C ,p)\=  ve 

is  a  corollary  of  Theorem  3.7.  Finally  assume  the  premise  of  (4.3)  and  use 
the  above  results  to  obtain  the  desired  result.  ■ 

Exercise  4.4  Show  that  the  relation  Rcfa  defined  in  Example  4.4  is  gen¬ 
erated  by  the  representation  function  /?cfa  also  defined  in  Example  4.7.  To 
do  so  prove  that 

v  i?CFA  (p,v)  iff  Pcfa(v)  Ccfa  (p,v) 

by  induction  on  the  size  of  v;  only  the  case  where  v  is  close  t  in  p  is  non¬ 
trivial.  ■ 


270 


ABSTRACT  INTERPRETATION 


Exercise  4.5  Define  =  (V{Vi),C)  (for  i  =  1,2)  and  define  fp  :  Li  -» 
L2  by 

fp(h)  =  {V2  e  V2  I  3ui  6  /l  :  p  b  Vi  v2} 

Show  that  fp  is  monotone.  Next  show  that  (p  I-  •  )(Ri  -*  R2)  fp  where 
Vi  Ri  U  is  defined  by  V{  £  h-  Also,  show  that  for  /'  :  L\  -»•  L2  we  have 
(p  h  •  -)(Ri  R2)  f  if  and  only  if  fp  C  f.  A  semantics  that  associates  a 

program  p  with  fp  as  defined  here  is  sometimes  called  a  collecting  semantics. 
Finally,  note  that  Ri  is  generated  by  pi  defined  by  /J,(v»)  =  {n.};  show  that 

fP  =  (fii  -*  A)(pi-  •)•  ■ 

Exercise  4.6  Show  that  all  of 


•  U 

•  A(fi,i2).T 


A(/i,I2). 


h  if  I2  E  h 

T  otherwise 

l2  if  /j  =  A 
h  HhQh  A  h ± 1 
T  otherwise 

h  U  l2  if  l\  C  I'M  l2  C  li 
T  otherwise 


are  upper  bound  operators  (where  l'  is  some  element  of  L).  Determine  which 
of  them  that  are  also  widening  operators.  Tiry  to  find  sufficient  conditions  on 
l'  such  that  the  operator  involving  l1  is  a  widening  operator.  ■ 


Exercise  4.7  Show  that  if  L  satisfies  the  Ascending  Chain  Condition  then 
an  operator  on  A  is  a  widening  operator  if  and  only  if  it  is  an  upper  bound 
operator.  Conclude  that  if  L  satisfies  the  Ascending  Chain  Condition  then 
the  least  upper  bound  operator  U:LxA->Aisa  widening  operator.  ■ 

Exercise  4.8  Consider  changing  the  definition  of  f%  from  /y  =  A  to 
=  l0  for  some  Iq  €  L.  Possible  assumptions  on  l0  are: 

•  lo  -  /(A); 

.  l0  =  /27(A); 

•  lo  G  Ext{f ); 

•  lo  arbitrary. 
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Which  of  these  suffice  for  proving  Fact  4.14  and  Proposition  4.13?  ■ 


Exercise  4.9  Let  Vr  be  as  in  Example  4.15  and  define 


inti  V  ink 


{inti  LI  ink  if  intiQint!  V  inkQinti 
inti  Vr  ink  otherwise 


where  ini  is  an  interval  satisfying  infant')  >  — oo  and  sup(inf')  <  oo.  Show 
that 

Vinti,  ink  •  ink  V  ink  Q  inti  Vr  ink 


and  that  the  inequality  may  be  strict.  Show  that  V  is  an  upper  bound 
operator.  Determine  whether  or  not  V  is  a  widening  operator.  ■ 


Exercise  4.10  Let  (/„)„  be  a  descending  chain  and  let  A  :  L  x  L  -4  L  be 
a  total  function  that  satisfies  1'2  Q  l[  =>  l2  E  (l[  A  l2)  C  l[  for  all  l[,l2  G  L. 
Show  that  the  sequence  (Z^)„  is  a  descending  chain  and  that  □  ln  for  all 
n.  ■ 


Exercise  4.11  Consider  the  following  alternative  strategy  to  narrowing 
for  improving  the  approximation  /y  €  Rcd(f)  to  the  fixed  point  lfp{f )  of  /  : 
L  L.  A  descending  chain  truncator  is  a  function  T  that  maps  descending 
chains  (Z„)n  to  a  non-negative  number  such  that 

if  (Z„)„  and  (l'n)n  axe  descending  chains  and  Vn  <  T((Zn)n)  :  /„  =  l'n 
then  T((Z„)„)  =  T((Z;)n). 

This  ensures  that  T  is  finitely  calculatable.  The  truncated  descending  chain 
then  is 

where  m'  =  T((/n(/y  ))„)  and  the  desired  approximation  to  lfp(f)  is 

i^v  =  /m'(/v) 

Prove  that  this  development  can  be  used  as  an  alternative  to  narrowing  and 
try  to  determine  the  relationship  between  the  two  concepts.  ■ 


Exercise  4.12  Show  that  if  L  satisfies  the  Descending  Chain  Condition 
then  the  binary  greatest  lower  bound  operator  n  :  L  x  L  -¥  L  is  &  narrowing 
operator.  ■ 
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Exercise  4.13  Consider  the  complete  lattice  Interval  of  Figure  4.2  and 
the  complete  lattice  Sign'  of  Figure  4.10  and  define  tis<  by 

TlS'CO  =  [-00,00]  7iS'(-0)  =  [-oo,0] 

71S'(0+)  =  [0, 00]  TtS'(-)  =  [-oo,-l] 

71S'(°)  =  [0, 0]  7iS'(+)  =  [l,oo] 

TiS'  (-L)  =  J. 

Show  that  there  exists  a  Galois  connection  between  Interval  and  Sign'  with 
TiS'  as  the  upper  adjoint.  ■ 


Exercise  4.14  Let  (V(V),av,jv,V(D))  be  a  Galois  connection  that  is 
given  by  an  extraction  function  r):V  ->  D.  Show  that  an  is  surjective  if  and 
only  if  77  is.  Conclude  that  (/P(V),ar),'yv,'P(D))  is  a  Galois  insertion  if  and 
only  if  77  is  surjective.  Next  show  that  sn[P{D)}  =  an\P{V)\  is  isomorphic 
(see  Appendix  A)  to  V(r)[V])  where  rj[V]  is  the  image  of  77  and  finally  verify 
that^F')  =  V'nr)[V].  m 


Exercise  4.15  Assume  that  the  Galois  connections  (V(Di),aVt+1 , 7n,+1  , 
V(Di+i))  are  given  by  the  extraction  functions  7?i+i  :  Di  — >  D{+\ .  Show  that 
the  composition  of  the  Galois  connections,  ( V(Do),a,j,V(D2 )),  will  have 
a  =  aV2  o  ani  =  aV30r n  and  7  =  7 m  °  JV2  =  7V2oVl ;  i.e.  the  Galois  connection 
is  given  by  the  extraction  function  772  o  rji .  ■ 

Exercise  4.16  Let  {V(V1),aU7u'P(Di))  and  ( V(V2),a2,72,V(D2 ))  be 
Galois  connections  given  by  the  extraction  functions  771  :  Vi  ->  -Di  and  772  : 
V2  ->  L>2-  Furthermore  assume  that  Vj  and  V2  are  disjoint  and  similarly  for 
D 1  and  D%.  Define  an  extraction  function 

77 :  Vx  U  V2  — >  Di  U  D2 


by 


if  v  €  V\ 
if  u  G  V2 


Show  that  this  defines  a  Galois  connection 


(V(V1UV2),a,l,7VlV(D1UD2)) 
and  reformulate  it  as  an  isomorphic  Galois  connection 


(W)  X  m),a„7„m)  X  V(D2)) 


in  the  manner  of  the  independent  attribute  method.  How  important  is  it 
that  Vi  and  V2  are  disjoint  and  that  D\  and  D2  are  disjoint?  ■ 
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Exercise  4.17  Let  (£1,01,71, Mi)  and  (£2,02, 72, M2)  be  Galois  inser¬ 
tions.  First  define 


a(luh)  =  (ai(/i),a2(/2)) 

7(mi,m2)  =  (71(^1)172(^2)) 

and  show  that  (£1  x  £2,0,7,  Mi  x  M2)  is  a  Galois  insertion.  Then  define 

o(/)  =  o2  o  /  0  71 

7(9)  =  l2°9°a\ 

and  show  that  (£1  -»  £2,o,7,  Mi  ->  M2)  is  a  Galois  insertion.  ■ 

Exercise  4.18  Let  (7>(Vi),oi,7i,P(£>i))  and  (7’(^2),o2,72,77(£)2))  be 
Galois  insertions.  Define 

a{VV)  =  |J{oi({tii})  x  o2({ti2})  |  (ui,v2)  €  FF} 
j(DD)  =  {(111,112)  |  ai({ui})  x  a2({n2})  C  £>£>} 

and  determine  whether  or  not  ( V{V\  x  V2),a,j,V(Di  x  D2))  is  a  Galois 
insertion.  ■ 

Exercise  4.19  Let  (£,  01,71,  Mx)  and  (£,o2,72,M2)  be  Galois  insertions. 
Define 


o(l)  =  (01  (1),  o2(l)) 

7(mi,m2)  =  7i(mi)ri72(m2) 

and  determine  whether  or  not  (£,  o,  7,  Mi  x  M2)  is  a  Galois  insertion.  ■ 

Exercise  4.20  Let  (£1,01,71,  Mi)  be  a  Galois  connection  and  define 

<*(/)  =  <*1  0  /  0  7i 
7(5)  =  7i  0  5  0  <*1 

(in  the  manner  of  Section  4.4).  Do  any  of  the  following  equalities 

o(Al.l)  =  A  m.m  'y(Xm.m)  =  A  1.1 

a(h°h)  =  oi(fi)oa(f2)  1(91  °  92)  =  7(51) 0  7(02) 


necessarily  hold?  Which  of  the  equalities  hold  when  (£1 , 01 , 71 ,  Mi )  is  known 
to  be  a  Galois  insertion?  ■ 
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Exercise  4.21  Consider  the  Galois  insertion 

(P{Z  x  Z),assR',7SSR',^’(AB)) 
developed  in  Example  4.39.  Determine  for  each  of  the  sets 

{(x,y)  |  x  =  y} 

{(x,y) !  *  =  -y} 

{(x,y)  |®  =  j/  +  l} 

{(x,y)  |  x  =  y  +  3} 

{(x,y)  |  x  >  y) 

{(x,y)  |x>j/  +  l} 

{( x,y )  |  x2  +  y2  <  100} 

the  best  description  in  T’(AB).  ■ 

Exercise  4.22  Let  (Lj,aj,7i,Mi)  be  Galois  connections  for  i  =  1,2,3. 
Use  the  approach  of  Section  4.4  to  define 

a(f)  =  ... 

7  (g)  =  ■■■ 

such  that  (( Lx  x  L2)  ->  L3,a,7,  (Mi  x  M2)  -4  M3)  is  a  Galois  connection. 
Next  let  all  of  be  the  Galois  connection 

(V(Z),  aZi,  7zi,  Interval) 

of  Example  4.19  that  relates  the  set  of  integers  to  the  intervals.  Let  plus  : 
P(Z)  x  V{Z)  -4  V(Z)  be  the  “pointwise”  application  of  addition  defined  by: 

X(Zi,  Z2)-{zi  +  Z2  |  Z\  E  Z\  A  z2  G  ^2} 

Next  define 

a(plus)  =  A(*nti,  infe).  •  •  • 

and  supply  the  details  of  the  definition.  ■ 

Exercise  4.23  Let  L  be  the  complete  lattice  of  sets  of  integers,  let  M 
be  the  complete  lattice  of  intervals  of  Example  4.10,  let  (L,a,7,  M)  be  the 
Galois  insertion  of  Example  4.19,  and  let  Vm  :  M  x  M  — >  M  be  the  widening 
operator  of  Example  4.15.  Observe  that  the  formula 

h^Lh  =  7(Q(^i)%a(l2)) 

defines  a  widening  operator  Vi  :  L  x  L  -4  L  and  develop  a  formula  for  it  (in 
the  manner  of  the  formula  for  Vm  of  Example  4.15).  ■ 
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Exercise  4.24  Suppose  that  (L,a,7,  M)  is  a  Galois  connection  or  a  Ga¬ 
lois  insertion  and  that  possibly  M  satisfies  the  Descending  Chain  Condition. 
Let  Am  :  M  x  M  4  M  be  a  narrowing  operator  and  try  to  determine  if  the 
formula 

hALh  =  l(a(h)AMa(h)) 

defines  a  narrowing  operator  A l  :  L  x  L  L.  m 
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Chapter  5 

Type  and  Effect  Systems 


So  far  our  techniques  have  applied  equally  well  to  typed  and  untyped  pro¬ 
gramming  languages.  This  flexibility  does  not  apply  to  the  development  to 
be  performed  in  this  chapter:  here  we  demand  that  our  programming  lan¬ 
guage  is  typed  because  we  will  use  the  syntax  for  types  in  order  to  express  the 
program  analysis  properties  of  interest  (as  was  already  illustrated  in  Section 
1.6). 

We  shall  first  present  an  Annotated  Type  System  for  Control  Flow  Analy¬ 
sis  in  Section  5.1,  demonstrate  its  semantic  soundness  and  other  theoretical 
properties  in  Section  5.2,  and  then  in  Section  5.3  show  how  to  obtain  an 
algorithm  for  computing  the  annotated  types  (and  prove  that  it  is  sound  and 
complete).  In  Sections  5.4  and  5.5  we  give  examples  of  other  analyses  spec¬ 
ified  by  Type  and  Effect  Systems.  In  Section  5.4  we  study  Type  and  Effect 
Systems  with  rules  for  subtyping,  polymorphism  and  polymorphic  recursion 
and  illustrate  their  use  in  an  analysis  for  tracking  Side  Effects,  an  Exception 
Analysis  and  an  analysis  for  Region  Inference.  Finally,  in  Section  5.5  we  show 
that  the  annotations  can  be  given  more  structure  and  we  illustrate  this  for  a 
Communication  Analysis. 


5.1  Control  Flow  Analysis 

Syntax  of  the  Fun  language.  To  illustrate  the  approach  we  shall 
make  use  of  the  functional  language  Fun  also  considered  in  Chapter  3;  that 
the  approach  also  applies  to  the  imperative  language  of  Chapter  2  was  briefly 
sketched  in  Section  1.6.  However,  in  this  chapter  we  shall  use  a  slightly 
different  labelling  scheme  from  the  one  in  Chapter  3;  the  syntactic  category 
of  interest  is 

e  €  Exp  expressions 
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and  it  is  defined  by: 

e  ::=  c  \  x  \  fn*  x  =>  eo  |  fun*  f  x  =>  e o  |  ei  e 2 

|  if  eo  then  ej  else  e 2  |  let  re  =  ei  in  \  e\  op  ei 

The  program  points,  n  £  Pnt,  are  used  to  name  the  function  abstractions  in 
the  program;  this  could  also  be  done  using  the  notion  of  labelled  terms  from 
Chapter  3  but  for  the  present  purposes  we  do  not  need  the  full  generality 
of  this  machinery  -  the  reason  is  that  now  we  will  use  the  types  to  record 
information  that  was  previously  associated  with  labels.  Hence  our  syntax 
just  makes  use  of  expressions  and  dispenses  with  terms. 

As  in  the  previous  chapters  we  shall  assume  that  a  countable  set  of  variables 
is  given  and  that  constants  (including  the  truth  values),  binary  operators 
(including  the  natural  arithmetic,  boolean  and  relational  operators)  and  pro¬ 
gram  points  are  left  unspecified: 


c  e 

Const 

constants 

op  £ 

Op 

binary  operators 

f,x  £ 

Var 

variables 

Tt  £ 

Pnt 

program  points 

Example  5.1  The  functional  program  (fn  x  =>  x)  (fn  y  =>  y)  con¬ 
sidered  in  Chapters  1  and  3  is  now  written  as 

(fnx  x  =>  x)  (fny  y  =>  y) 

just  as  we  did  in  Example  1.5.  ■ 


Example  5.2  The  expression  loop  of  Example  3.2  is  now  written: 

let  g  =  (funp  f  x  =>  f  (fny  y  =>  y)) 
in  g  (fnz  z  =>  z) 

Recall  that  this  is  a  looping  program:  g  is  first  applied  to  the  identity  function 
fnz  z  =>  z  but  it  ignores  its  argument  and  calls  itself  recursively  with  the 
function  fny  y  =>  y.  ■ 

5.1.1  The  Underlying  Type  System 

The  analyses  will  be  specified  as  extensions  of  the  ordinary  type  system  in 
order  to  record  the  program  properties  of  interest.  For  this  reason  the  or¬ 
dinary  type  system  is  sometimes  called  the  underlying  type  system  and  we 
shall  start  by  specifying  it. 
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r  I“UL  c  :  Tc 

T  I“ul  x  :  t  if  T(a:)  =  r 

T[i  tx ]  buL  e0  :  T0 

T  buL  fn*  x  =>  e0  :  tx  ->  r0 

T[/  tx  -»  rpl[a;  H-  r^]  bUL  e0  :  r0 
T  bui_  fun*  /  x  =>  e0  :  rx  ->  r0 

r  bUL  ex  :  T2  -4  rp  T  bui,  e2  :  T2 
r  buL  ei  e2  :  ro 

r  buL  :  bool  r  buL  ei  :  r  T  buL  e2  :  r 
F  buL  if  eo  then  e\  else  e2  :  r 

T  buL  ei  :  rx  £[x  n]  bUL  e2  :  r2 
T  buL  let  x  -  e\  in  e2  :  r2 

r  bUL  ei  :  T  bUL  e2  :  r^p 

r  buL  ej  op  e2  :  Top 


Table  5.1:  The  Underlying  Type  System. 

Types.  Let  us  first  introduce  the  notions  of  types  and  type  environments: 

t  €  Type  types 
T  e  TEnv  type  environments 

We  shall  assume  that  the  types  are  given  by 

r  int  |  bool  |  Ti  -»  r2 

where  int  and  bool  are  the  only  two  kinds  of  base  types  and  as  usual  we 
use  arrows  for  function  types.  Each  constant  c  €  Const  has  a  type  that  we 
shall  denote  rc  so  e.g.  true  has  type  rtrue  =  bool  and  7  has  type  77  =  int. 
Each  binary  operator  op  will  expect  two  arguments  of  type  r*p  and  r^p, 
respectively,  and  give  a  result  of  type  rop  -  an  example  is  the  relational 
operation  <  that  expects  two  arguments  of  type  int  and  gives  a  result  of 
type  bool.  For  the  sake  of  simplicity  we  shall  assume  that  all  the  constants 
have  base  types  and  that  all  binary  operators  expect  arguments  of  base  types 
and  return  values  of  base  types. 

The  type  environments  are  given  by: 

r  ::=  []  I  r[x  r] 


[con] 

[t>ar] 

IM 

[fun] 

[app] 

m 

[let] 

[op] 
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Formally,  T  is  a  list  but  nevertheless  we  shall  feel  free  to  regard  it  as  a  finite 
mapping:  we  write  dom(r)  for  {x  |  T  contains  [x  •  •  •]};  we  write  T(x)  =  r 
if  x  e  dom( r)  and  the  rightmost  occurrence  of  [i  H  ■  ■  ■]  in  T  is  [x  M-  r], 
and  we  write  T|X  for  the  type  environment  obtained  from  T  by  removing 
all  occurrences  of  [x  •  •  •]  with  x  X.  For  the  sake  of  readability  we  shall 
write  [ x  r]  for  [  ][x  t-j-  r]. 

Typing  judgements.  The  general  form  of  a  typing  is  given  by 


T  Ful  e  :  t 

that  says  that  the  expression  e  has  type  r  assuming  that  any  free  variable 
has  type  given  by  T.  The  axioms  and  rules  for  the  judgements  are  listed  in 
Table  5.1  and  are  explained  below. 

The  axioms  [con]  and  [var]  are  straightforward:  the  first  uses  the  predefined 
type  for  the  constant  and  the  second  consults  the  type  environment.  In  the 
rules  [fn]  and  [fun]  we  guess  a  type  for  the  bound  variables  and  determine 
the  types  of  the  bodies  under  the  additional  assumptions;  the  rule  [fun ]  has 
the  implicit  requirement  that  the  guess  of  the  type  for  /  matches  that  of  the 
resulting  function.  As  a  consequence  of  these  two  rules  the  type  system  is 
nondeterministic  in  the  sense  that  T  Ful  e  :  7i  and  F  Ful  e  :  r2  does  not 
necessarily  imply  that  n  =  r2. 

The  rule  [app]  requires  that  the  operator  and  the  operand  of  the  application 
can  be  typed  and  implicitly  it  requires  that  the  type  of  the  operator  is  a 
function  type  where  the  type  before  the  arrow  equals  that  of  the  operand 
-  in  this  way  we  express  that  the  types  of  the  formal  and  actual  parameter 
must  be  equal. 

The  rules  [if\,  [let]  and  [op]  axe  straightforward.  In  particular,  the  let- 
construct  let  x  =  e\  in  e2  admits  exactly  the  same  typings  as  the  application 
(fn*  x  =>  e2)  e\  and  regardless  of  the  choice  of  re.  In  Sections  5.4  and  5.5 
we  shall  consider  a  polymorphic  let-construct  where  let  x  =  e\  in  e2  may 
admit  more  typings  than  (fn*  x  =>  e2)  e\. 

Example  5.3  Let  us  show  that  the  expression  loop 

let  g  =  (fun?  f  x  =>  f  (fny  y  =>  y)) 
in  g  (fnz  z  =>  z) 

of  Example  5.2  has  type  r  ->  r  for  each  type  r.  We  shall  first  consider  the 
expression  funp  f  x  =>  f  (fny  y  =>  y)  where  we  write  Ffx  for  the  type 
environment  [f  H  (t  -+  r)  ->  (t  4  r)][x  r  ->  r].  Then  we  get 


Ffx  Ful  f  :  (t  -»  t)  -*  (t  ->  t) 
ffx  Ful  fny  y  =>  y  :  r  ->■  t 
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using  the  axiom  [var]  and  the  rule  [fn].  The  rule  [app]  then  gives 
Tfx  hut  f  (fny  y  =>  y)  :  r  -4  r 

and  we  have  a  judgement  matching  the  premise  of  the  rule  [fun].  Hence  we 
get 

[  ]  (— ul  fun?  f  x  =>  f  (fny  y  =>  y)  :  (r  -4  r)  -4  (r  -4  r) 

Taking  Tg  to  be  the  type  environment  [g  H  (r  ->  r)  ->  (r  -4  r)]  we  get 

Fg  huL  g  (fnz  z  =>  z )  :  r  -4  r 

using  the  axiom  [var]  and  the  rules  \fn]  and  [app].  The  rule  [let]  can  now  be 
used  to  show  that  the  expression  loop  has  type  r  -4  r.  ■ 

5.1.2  The  Analysis 

Annotated  types.  That  a  function  has  type  tx  -4  T2  means  that  given 
an  argument  of  type  T\  it  will  return  a  value  of  type  T2  in  case  it  terminates. 
To  get  a  Control  Flow  Analysis  we  shall  annotate  the  type  with  information, 
< p  6  Ann,  about  which  function  it  might  be.  The  annotations  are  given  by 

€  Ann  annotations 

where: 

<P  ::=  {-7r}  |  <pi  U  <p2  |  0 

So  ip  will  be  a  set  of  function  names'-  describing  the  set  of  function  definitions 
that  can  result  in  a  function  of  a  given  type;  as  will  be  discussed  below,  we 
shall  feel  free  to  write  {7Ti, . . . , 7rn}  for  {^ }  U  •  •  •  U  {7rn}.  We  now  take 


T 

«.  -  ' 

€  TjT>e 

'  ”  J  V  J  \  J 

annotated  types 

P 

G  TEnv 

annotated  type  environments 

and  define: 

r  ::= 

int  |  bool  |  Ti  ?2 

f  ::= 

[  ]  I  f  [*  H4  f] 

We  shall  write  [fj  for  the  underlying  type  corresponding  to  the  annotated 
type  f;  it  is  defined  as  follows: 

[intj  =  int 
[boolj  =  bool 
Ifi  r2j  =  |nj  -4  [t2J 

As  an  example  we  have  [int  -^4  intj  =  (int  -4  int).  Furthermore,  we 
extend  the  notation  to  operate  on  type  environments  so  [rj(a:)  =  [F(a;)J  for 
all  x. 
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[con] 

[nar] 

\M 

[fun] 

[app] 

M 

[let] 

[op] 


T  Fcfa  c  :  rc 

T  F cfa  x  :  f  if  T(x)  =  t 

Tfo  >->  tx]  hcFA  eo  :  r0 
f  Fcfa  fn*  x  =>  e0  :  %  r0 

f  [/  f8  f0][a;  i->  fa]  hCFA  e0  :  f0 

f  FCfa  fun*  /  x  =>  e0  :  fx  WUv>>  f0 

T  Fcfa  ei  :  f2  -^4  r0  T  Fcfa  e2  •  T2 
T  Fcfa  ei  e2  :  r0 

f  I~cfa  ep  :  bool  T  I~cfa  e\  :  r  f  Fcfa  e2  :  f 
r  Fcfa  if  eo  then  e\  else  e2  :  r 

f  Fcfa  ei  :  n  f[a;  i-»  rj]  FCfa  :  r2 
T  Fcfa  let  z  =  ei  in  e2  :  f2 

f  Fcfa  &i  :  r]p  f  Fcfa  e2  :  r2op 


T  Fcfa  ei;  op  e2  :  r, 


op 


Table  5.2:  Control  Flow  Analysis. 


Judgements.  The  judgements  of  the  Control  Flow  Analysis  have  the 
form 

f  Fcfa  e  :  r 

and  are  defined  by  the  axioms  and  rules  of  Table  5.2.  The  clauses  [fn]  and  [fun] 
annotate  the  arrow  of  the  resulting  function  type  with  the  information  that 
the  abstraction  named  tt  should  be  included  in  the  set  of  possible  functions; 
the  use  of  {7r}  U  </?  indicates  that  we  may  want  to  include  other  names  as  well 
and  we  shall  say  that  the  Type  and  Effect  System  allows  subeffecting  (see 
the  Concluding  Remarks).  In  Example  5.5  below  we  shall  give  an  example 
where  subeffecting  is  indeed  needed  to  analyse  the  expression.  The  remaining 
clauses  of  Table  5.2  are  straightforward  modifications  of  the  similar  clauses 
of  Table  5.1. 

Example  5.4  Let  us  return  to  the  expression 


(fnx  x  =>  x)  (fny  y  =>  y) 
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of  Example  5.1.  Writing  fy  for  int  int  we  have  the  following  inference 
tree: 

[x  7y]  hcFA  x  :  7V  [y  •->  int]  hCFA  y  :  int 

[  ]  I-cfa  f  nx  x  =>  x  :  7V  fy  [  ]  (-Cfa  fnY  y  =>  y  :  tv 
[  ]  hCFA  (fnx  x  =>  x)  (fnY  y  =>  y)  :  fy 

Note  that  the  whole  inference  tree  is  needed  to  get  full  information  about  the 
control  flow  properties  of  the  expression.  If  we  label  all  the  subexpressions 

((fnx  x  =>  x1)2  (fny  y  =>  y3)4)5 

as  in  Chapter  3  then  we  can  list  the  types  of  the  subexpressions  as  follows 


l 

i 

2 

3 

4 

5 

CM 

fy 

7y  fy 

int 

fy 

fy 

and  we  are  close  to  the  information  supplied  by  C  in  Chapter  3.  The  infor¬ 
mation  corresponding  to  p  can  be  obtained  by  “merging”  information  from 
the  various  type  environments  of  the  inference  tree  (see  Exercise  5.4).  ■ 

Example  5.5  Consider  once  again  the  expression  loop 

let  g  =  (funp  f~x  =>  f  (fny  y  =>  y)) 
in  g  (fnz  z  =>  z) 

and  let  us  write  Tfx  for  [f  t->  (f  ^Y,z^>  f)  (r  -b  ?)][x  h*  t  -^Y|Z^>  r]. 
Using  the  clause  [/h]  we  have 

~  {Y  Z} 

Tfx  I-CFA  fny  y  =>  y  :  f  — 1— >  r 

where  we  exploit  that  subeffecting  allows  us  to  enlarge  the  annotation  from 
the  minimal  {Y}  to  (Y,  Z}.  Using  this  we  can  construct  an  inference  tree  for: 

[  ]  I-cfa  funp  f  x  =>  f  (fny  y  =>  y)  :  (r  r)  ►  (f  A  f) 

Next  let  rg  be  [g  h*  (r  Mz}>  r)  -^b  (r  -b  f)].  We  now  exploit  that  the 
annotation  {Z}  can  be  enlarged  to  {Z,  Y}  in  the  clause  \fn]  so  that: 

-  ^  {z.y}  ^ 

rg  I-cfa  fnz  z  =>  z  :  r  - >  t 


Since  {Z,  Y}  =  {Y,  Z}  we  can  use  the  clause  [app]  and  get 
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[unit] 

tp  =  <p  U  0 

[idem] 

tp  =  ipUtp 

[com] 

<Pl  U  <P2  =  <P2  u  <Pi 

[ass] 

<Pi  u  (tp2  u  tpz)  =  (tpi  u  ^2)  u  tp3 

[trans] 

(p  =  (p 

[ref] 

<Pl  =<fi2  <P2=  <P3 

[cong] 

<Pl  =  <Pl  <P 2  =  V>2 

<Pl  =  <^3 

<Pl  U  tp2  -  tp[  U  tp'2 

Table  5.3:  Equality  of  Annotations. 

and  eventually  [  ]  Hcfa  loop  :  ?  f.  This  can  be  interpreted  as  saying 
that  the  expression  loop  does  not  terminate:  the  type  is  f  f  but  the 
annotation  0  indicates  that  there  will  be  no  function  abstractions  with  the 
given  type. 

Actually  we  can  show 

[  ]  F-cfa  funF  f  x  =>  f  (fnY  y  =>  y)  :  (r  *---4  f)  (f  A  r) 

for  every  annotation  tp  and  hence  we  have  [  j  Fcfa  loop  :  f  -£»  f  for  every 
annotation  tp;  clearly  the  judgement  with  tp  =  0  is  the  most  informative.  ■ 

Equivalence  of  annotations.  There  are  a  few  subtleties  involved 
in  using  this  simple-minded  system  for  Control  Flow  Analysis.  One  is  the 
implicit  decision  to  regard  a  type  like  r  ^Y,z^>  f  as  being  equal  to  r  ?. 

Concerning  this  subtlety,  we  already  explained  that  we  feel  free  to  write 
{7Ti,  •  •  • , 7rn}  for  {7rj}  U  •  •  •  U  {tt„}.  To  be  utterly  formal  we  should  really  say 
that  we  write  {7^, . . .  ,7r„}  for  ((0  U  {7Ti })  U  •  •  •)  U  {7r„}. 

Next  we  allow  to  replace  t\  72  by  n  T2  whenever  <p\  and  tp2  are 
“equal  as  sets” .  To  be  utterly  formal  this  can  be  axiomatised  by  the  axioms 
and  rules  of  Table  5.3:  the  axioms  [unit],  [idem],  [com]  and  [ass]  express  that 
set  union  has  a  unit  and  is  idempotent,  commutative  and  associative,  and  the 
axioms  and  rules  [trans],  [ref]  and  [cong]  ensure  that  equality  is  an  equivalence 
relation  as  well  as  a  congruence. 

Finally,  we  allow  to  replace  ?i  by  ?2  if  they  have  the  same  underlying  types 
and  all  annotations  on  corresponding  function  arrows  are  “equal  as  sets” .  To 
be  utterly  formal  we  could  axiomatise  this  by: 

f  =  f  TLfzl 1  *2  =  %  <p  =  <p' 

in  -2*  T2)  =  (t[  r') 

It  is  customary  to  be  informal  about  these  fine  technical  points.  But  to 
avoid  confusion  one  should  at  the  very  least  point  out  that  annotations  are 
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considered  equal  modulo  the  existence  of  a  unit,  commutativity,  associativity, 
and  idempotence;  the  abbreviation  UCAI  is  often  used  for  this. 

Conservative  extension.  Another  subtlety  is  the  ability  to  give  the 
abstraction  fny  y  =>  y  the  type  f  ^Y,z^>  r.  Suppose  for  a  moment  that  the 
two  rules  for  function  abstraction  did  not  have  a  {7r}  U  <p  annotation  on  the 
function  arrows  but  only  a  {tt}.  Then  fny  y  =>  y  would  have  type  f  r 
but  not  ?  ^Y,Z-4  f;  consequently  the  program  from  Example  5.5  would  have 
no  type  in  the  Annotated  Type  System  for  Control  Flow  Analysis!  This  is  a 
very  undesirable  property:  we  ought  to  be  able  to  analyse  all  programs. 

To  ensure  that  our  system  does  not  have  the  above  deficiency  we  shall  for¬ 
mally  prove  that  the  Control  Flow  Analysis  of  Table  5.2  is  a  conservative 
extension  of  the  underlying  type  system  of  Table  5.1.  This  is  expressed  by: 

Fact  5.6 

(i)  If  f  h cfa  e  :  f  then  |fj  Hul  e  :  |tJ • 

(ii)  If  T  bui  e  :  r  then  there  exists  F  and  r  such  that 

f  h cfa  e  :  f,  [fj  =  T  and  [fj  =  r.  ■ 

Proof  The  proof  of  (i)  is  straightforward.  For  the  proof  of  (ii)  one  annotates  all 
arrows  with  the  set  of  all  program  points  in  e.  ■ 

This  result  paves  the  way  for  extending  [-J  to  operate  on  entire  typings: 
applied  to  the  typing  T  Fcfa  e  :  f  it  produces  a  typing  of  the  form  [rj  Ful 
e  :  [f  J .  As  an  example,  the  typing  of  Example  5.5  is  transformed  into  the 
typing  of  Example  5.3  (assuming  that  [fj  =  r). 

In  Section  5.4  we  shall  study  explicit  inference  rules  for  subeffecting :  this  is 
a  related  technique  for  ensuring  that  the  analysis  is  a  conservative  extension 
of  the  underlying  type  system. 
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Having  specified  the  analysis  we  shall  now  ensure  that  it  is  semantically 
correct.  Furthermore,  the  fact  that  the  analysis  is  a  conservative  extension 
of  the  underlying  type  system  motivates  the  following  result:  whenever  we 
have  a  typing  in  the  underlying  type  system  then  the  set  of  typings  of  the 
Control  Flow  Analysis  constitutes  a  Moore  family.  So  as  in  Section  3.2  (and 
Exercise  2.7)  every  acceptable  expression  can  be  analysed  and  it  has  a  best 
analysis. 

As  in  Sections  2.2  and  3.2,  the  material  of  this  section  may  be  skimmed 
through  on  a  first  reading;  however,  we  re-iterate  that  it  is  frequently  when 
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[con]  I-  c  — >  c 

\M  F  (fn*  x  =>  e0)  — y  (fn*  x  =>  e0) 

|/un]  F  (fun*  /  x  =>  e0)  — >  fn*  a:  =>  (e0[/  fun*  f  x  =>  e0]) 


[<*PP] 

[i/J 

[*/s] 

[op] 


F  e\  — y  (fn*  x  =>  e0)  F  e2  — >■  v2  F  ep[x  H-  v2] 
F  ei  e2  — y  v0 


Vo 


F  eo 


true  F  ei 


Vl 


F  if  eo  then  ei  else  e2  — y  Vi 

F  eo  — y  false  F  e2  — y  v2 
F  if  eo  then  ei  else  e2  — y  v2 

F  ei  — y  Vi  F  e2[x  »->  ux]  — y  v2 
F  let  x  =  ei  in  e2  — >  v2 

F  ei  — y  v\  F  e2  — >  v2 


F  ei  op  e2 


if  Vi  op  v2  =  v 


Table  5.4:  Natural  Semantics  for  Fun. 

conducting  the  correctness  proof  that  the  final  and  subtle  errors  in  the  anal¬ 
ysis  are  found  and  corrected! 

5.2.1  Natural  Semantics 

To  prove  the  semantic  correctness  of  the  analysis  we  need  to  define  the  se¬ 
mantics.  Many  kinds  of  semantics  would  be  appropriate  but  among  the 
operational  semantics  we  shall  now  prefer  a  Natural  Semantics  (i.e.  big-step 
operational  semantics)  without  environments  because  this  makes  semantic 
correctness  somewhat  easier  to  establish.  This  is  related  to  the  discussion  in 
the  Concluding  Remarks  of  Chapter  3  about  the  difference  between  using  a 
big-step  operational  semantics  without  environments  and  a  small-step  oper¬ 
ational  semantics  with  environments;  thus  our  correctness  statement  will  be 
somewhat  weak  in  case  of  looping  programs. 

Transitions.  The  Natural  Semantics  will  have  transitions  of  the  form 


meaning  that  the  expression  e  evaluates  to  the  value  v.  We  shall  assume  that 
e  €  Exp  is  a  closed  expression,  i.e.  FV(e)  =  0,  meaning  that  e  does  not  have 
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any  free  variables.  The  values 

v  €  Val  values 

will  be  a  subset  of  the  expressions  given  by  the  syntax 

v  ::=  c  j  fn*  x  =>  e<>  provided  that  FV(fn*  x  =>  eo)  =  0 

where  we  demand  that  values  are  closed  expressions.  Compared  to  the  Struc¬ 
tural  Operational  Semantics  of  Section  3.2,  it  is  not  necessary  to  introduce 
environments  since  the  bound  variables  will  be  syntactically  replaced  by  their 
value  as  soon  as  they  become  free.  Hence  there  is  no  need  for  a  close- 
construct  nor  for  a  bind-construct. 

As  usual  we  shall  write  ei[x  e2]  for  substituting  e2  for  all  free  occurrences  of 
x  in  ei .  It  will  be  the  case  that  e2  is  closed  whenever  we  use  this  notation  and 
therefore  there  is  no  risk  of  variable  capture  and  hence  no  need  to  rename 
bound  variables.  Throughout  we  shall  assume  that  fun*  f  x  =>  e o  uses 
distinct  variables  for  /  and  x.  The  semantics  is  given  by  Table  5.4  and  is 
explained  below. 

The  axioms  [con]  and  [fn]  express  that  the  constant  and  the  function  ab¬ 
straction,  respectively,  evaluates  to  themselves.  For  recursive  function  ab¬ 
stractions  we  shall  unfold  the  recursion  one  level  as  expressed  by  the  axiom 
[/tin];  note  that  the  function  abstraction  being  created  inherits  the  program 
point  of  the  recursive  function  abstraction.  The  rule  [app]  for  application 
expresses  that  first  we  evaluate  the11  operator,  then  the  operand,  and  next  we 
substitute  the  actual  parameter  for  the  formal  parameter  in  the  body  of  the 
abstraction  and  evaluate  the  body.  We  have  only  one  rule  for  application 
because  the  axiom  [fun]  ensures  that  all  function  abstractions  will  be  of  the 
form  fn*  x  =>  eo-  The  rules  for  the  conditional,  the  let-construct  and  the 
binary  operators  should  be  straightforward. 

Example  5.7  Consider  the  expression  (fnx  x  =>  x)  (fny  y  =>  y)  of  Ex¬ 
ample  5.1.  Using  the  axiom  [/h]  we  have 

h  fnx  x  =>  x  — >  fnx  x  =>  x 
h  fny  y  =>  y  — >  fny  y  =>  y 
h  x[x  fny  y  =>  y]  — >  fny  y  =>  y 

and  we  can  apply  the  rule  [app]  to  get: 

b  (fnx  x  =>  x)  (fny  y  =>  y)  — >  fny  y  =>  y 


In  Example  3.7  we  showed  how  the  Structural  Operational  Semantics  deals 
with  this  expression.  ■ 
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Example  5.8  Next  consider  the  expression  loop 

let  g  =  (funF  f  x  =>  f  (fny  y  =>  y)) 
in  g  (fnz  z  =>  z) 

and  let  us  see  how  this  looping  program  is  modelled  in  the  Natural  Semantics. 
First  we  observe  that  the  axiom  [fun]  gives 

t-  funF  f  x  =>  f  (fny  y  =>  y)  — > 

fnF  x  =>  ((funF  f  x  =>  f  (fny  y  =>  y))  (fnY  y  =>  y)) 

so  we  have  replaced  the  recursive  call  of  f  with  the  recursive  function  defini¬ 
tion  itself.  Turning  to  the  body  of  the  let-construct  we  have  to  replace  the 
occurrence  of  g  with  the  abstraction: 

fnF  x  =>  ((funF  f  x  =>  f  (fny  y  =>  y))  (fny  y  =>  y)) 

The  operator  will  now  evaluate  to  this  value  and  the  operand  fnz  z  =>  z 
will  evaluate  to  itself.  So  the  next  step  is  to  determine  a  value  v  such  that 
we  have  an  inference  tree  for 

h  (funF  f  x  =>  f  (fny  y  =>  y))  (fny  y  =>  y)  — >  v  (5.1) 

and  after  that  we  are  in  a  position  to  use  the  rule  for  application.  The  eval¬ 
uation  of  the  operator  in  (5.1)  proceeds  as  before  and  so  does  the  evaluation 
of  the  operand  and  once  more  we  are  left  with  the  obligation  to  construct  an 
inference  tree  for  the  judgement  (5.1).  Thus  we  have  encountered  a  circular¬ 
ity  and  we  see  that  the  looping  of  the  program  is  modelled  in  the  semantics 
by  the  absence  of  an  inference  tree.  In  Example  3.8  we  showed  how  the 
Structural  Operational  Semantics  deals  with  the  expression  loop.  ■ 

It  is  immediate  to  verify  that  if  e  is  a  closed  expression  and  h  e  — >  v  then 
all  h  e'  — >  v'  occurring  in  the  corresponding  inference  tree  (in  particular 
b  e  — >  v  itself)  will  have  both  e'  and  v'  to  be  closed. 

5.2.2  Semantic  Correctness 

To  be  able  to  express  the  semantic  correctness  of  the  analysis  we  need  to 
assume  that  the  types  of  the  binary  operators  op  and  their  semantics  are 
suitably  related.  Recall  that  for  the  underlying  type  system  we  assume  that 
op  takes  two  arguments  with  the  base  types  rlop  and  r%p  and  gives  a  result 
of  type  rop  and  since  base  types  do  not  have  any  annotations  we  shall  now 
assume  that: 


If  [  ]  FCFa  vi  :  rlop  and  [  ]  FCFa  *>2  :  T%p  then  [  ]  FCFa  v  :  r< 
where  v  =  v\  op  V2- 
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This  ensures  that  when  given  arguments  of  appropriate  types  the  operator 
will  return  a  value  of  the  expected  type. 

The  semantic  correctness  of  the  analysis  now  expresses  that  the  annotated 
type  foreseen  by  the  analysis  will  also  be  the  annotated  type  of  the  value 
obtained  by  evaluating  the  expression: 


Theorem  5.9 

If  [  ]  bcFA  e  :  f,  and  I-  e  — »  v  then  [  ]  I-cfa  «  :  f. 


It  follows  that  if  [  ]  h  e  :  ?i  %  and  I-  e  — >  fn *  x  =>  eo  then  7r  e  y>ol 
hence  the  analysis  correctly  tracks  the  closures  that  can  result  from  a  given 
expression.  Also  note  that  if  [  ]  h  e  :  fj  %  then  e  cannot  terminate. 

In  preparation  for  the  proof  of  the  theorem  we  need  a  few  technical  results 
of  the  sort  that  are  standard  for  type  systems.  The  first  result  expresses 
that  the  type  environment  may  be  extended  with  information  that  does  not 
influence  the  analysis  result: 

Fact  5.10  If  Ti  I-cfa  fi  :  t  and  Ti(x)  =  ^(x)  for  all  x  £  FV(e)  then 
T 2  H cfa  e  :  f.  ■ 

Proof  The  proof  is  by  induction  on  the  inference  tree  for  T i  I~cfa  e  :  r  using  that 
it  is  the  rightmost  occurrence  of  a  variable  in  a  type  environment  that  determines 
its  type.  ■ 

The  next  result  shows  that  we  can  safely  substitute  an  expression  of  the 
correct  annotated  type  for  a  variable: 

Lemma  5.11  Assume  [  ]  FCfa  e0  :  r0  and  T[x  f-f  f0]  Fcfa  e  :  r.  Then 
f  h cfa  e[x  f-f  e0]  :  f.  ■ 

Proof  The  proof  is  by  structural  induction  on  e.  Most  cases  are  straightforward 
so  we  shall  only  present  the  cases  of  variables  and  function  abstractions. 

The  case  y.  We  assume  that 

T[x  ?o]  I-cfa  y  :  r 

so  from  the  axiom  [uarj  of  Table  5.2  we  have  (T[x  f-f  ro])(y)  =  r.  If  x  =  y  then 
y[x  f^  eo]  =  eo  and  r  =  ro,  and  from  [  ]  I-cfa  eo  :  to  and  Fact  5.10  we  get  the 
required  F  I-cfa  eo  :  r.  If  x  #  y  then  y[x  ff  eo]  =  y  and  it  is  easy  to  see  that 
r  I-CFA  y  :  r. 

The  case  fnw  y  =>  e.  We  assume  that 

r[x  f-f  f0]  I-cfa  fn„  y  =>  e  :  ? 
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so,  according  to  rule  [fn]  of  Table  5.2,  it  must  be  the  case  that  r  =  ry  f' 

and: 

T[x  ?o][y  i-4  Ty]  hcFA  e  :  t7 

If  x  =  y  then  it  follows  from  Fact  5.10  that  T[y  t-4  ry]  I~cfa  e  :  t*  and  since 
(fn*  y  =>  e)[x  i-4  eo]  =  fn*  y  =>  e  the  result  follows.  So  assume  that  i  /  y; 
then  (fn*  j/  =>  e)[x  1-4  eo]  =  fn*  y  =>  (e[x  >-4  eo]).  It  follows  from  Fact  5.10  that 
r[y  t-4  Ty][x  i-4  to]  Pcfa  e  :  f'  and  then  we  get  T[y  f4  ry]  FCfa  e[x  1-4  eo]  :  r'  from 
the  induction  hypothesis.  Now  the  result  follows  using  the  rule  [fn],  m 

We  now  turn  to  the  proof  of  Theorem  5.9: 

Proof  The  proof  proceeds  by  induction  on  the  inference  tree  for  h  e  — >■  v. 

The  cases  [con]  and  [fn]  are  immediate. 

The  case  [fun].  We  assume  that 

fun*  f  x  =>  e 0  — >  fn*  x  =>  eo[/  >-4  fun*  /  x  =>  eo] 
where  /  and  x  are  distinct  variables.  Also  we  have 

[  ]  I-CFA  fun*  f  x  =>  eo  :rx  f0 

and  according  to  Table  5.2  this  is  because  [/  1-4  rx  ?o][x  >-4  rx]  Fcfa  eo  :  to. 

Since  [/  >-4  tx  to][x  1-4  tx]  equals  [x  >-4  rx][f  1-4  rx  ■  to]  (because 

we  assumed  that  /  and  x  are  distinct)  it  follows  from  Lemma  5.11  that 

vs. 

[x  Tx]  I-CFA  eo[/  fun*  /  x  =>  eo]  :  f0 

and  hence  [  ]  FCfa  fn*  x  =>  e0[/  *-4  fun*  f  x  =>  eo]  :  tx  To  which  is  the 

desired  result. 

The  case  [ app ].  We  assume  that 

P  ei  ei  — t  vo 

because  h  ei  — >  fn*  x  =>  eo,  I-  e 2  — >  V2  and  P  eo[x  i-4  V2]  — >  vo.  Also  we  have 

[  ]  P cfa  ei  e2  :  to 

and  according  to  Table  5.2  this  is  because  [  ]  Pcfa  ei  :  T2  to  and  [  ]  Fcfa  e2  :  ?2. 
The  induction  hypothesis  applied  to  the  inference  tree  for  e\  gives: 

[  ]  Pcfa  fn*  x  =>  eo  :  t2  f0 

According  to  Table  5.2  this  can  only  be  the  case  if  ir  €  and  [x  t-4  T2]  Pcfa  eo  :  To. 
The  induction  hypothesis  applied  to  the  inference  tree  for  e2  gives 

[  ]  Pcfa  V2  :  ?2 

and  by  Lemma  5.11  we  now  get  [  ]  Pcfa  eo[x  1-4  V2]  :  to.  The  induction  hypothesis 
applied  to  the  inference  tree  for  eo[x  1-4  V2]  now  gives 

[  ]  Pcfa  vq  :  to 
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and  this  is  the  desired  result. 

The  case  [i/i].  We  assume  that 

(-  if  eo  then  e\  else  ei  — »•  vi 
because  I-  eo  — Y  true  and  b  ei  — ►  v\.  Also  we  have 

[  ]  1“cfa  if  eo  then  e\  else  e.i  :  r 

and  from  Table  5.2  we  see  that  this  is  because  [  ]  I-cfa  eo  :  bool,  [  ]  Hcfa  e\  ■  r  and 
[  ]  I~cfa  ei  :  r.  The  induction  hypothesis  gives 

[  ]  Hcfa  vi  :  t 

and  this  is  the  desired  result. 

The  case  [t/2]  is  analogous. 

The  case  [let).  We  assume  that 

b  let  x  =  ei  in  e2  — Y  vi 

because  I-  ei  — Y  vi  and  b  ei[x  >-4  iq]  — >•  vi.  Also  we  have 

[  ]  hcFA  let  x  =  ei  in  e2  :  r2 

and  this  is  because  [  ]  bcFA  ei  :  n  and  [x  1-4  n]  I-cfa  e2  :  T2.  The  induction 
hypothesis  now  gives: 

[  ]  b cfa  t)i  :  ri 

Prom  Lemma  5.11  we  then  get  [  ]  bcp*  e2[x  1-4  ui]  :  ti  and  the  induction  hypothesis 
gives 

[  ]  be  FA  Vi  :  T1 

as  required. 

The  case  [op].  We  assume  that 

b  ei  op  ei  — ►  v 

because  b  ei  — >  vi,  h  ei  — >•  vi  and  vi  op  vi  =  v.  Also  we  assume 

[  ]  bcFA  ei  op  ei  \  ToP 

and  this  can  only  be  because  [  ]  bcFA  ei  :  ToP  and  [  ]  bcFA  e2  :  r„p.  The  induction 
hypothesis  gives  [  ]  bcFA  v\  :  rlT  and  [  ]  bcFA  vi  :  t„p  and  the  desired  result  that 
[  ]  bcFA  v  :  Top  then  follows  from  the  stated  assumptions  about  the  relationship 
between  the  semantics  and  the  types  of  the  binary  operators.  ■ 

5.2.3  Existence  of  Solutions 

In  Chapter  3  we  showed  that  the  set  of  solutions  to  the  Control  Flow  Analysis 
constituted  a  Moore  family:  the  greatest  lower  bound  of  a  set  of  solutions  is 
also  a  solution.  (Also  see  Exercise  2.7.)  From  that  result  it  then  follows  that 
all  programs  can  be  analysed  and  that  there  is  a  best  analysis. 
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Complete  lattice  of  annotations.  A  similar  development  is  pos¬ 
sible  here  except  that  special  care  has  to  be  taken  concerning  the  nature  of 
annotations.  We  would  like  to  be  able  to  regard  the  set  Ann  of  annotations 
as  a  complete  lattice,  and  this  necessitates  a  partial  ordering 

Vi  Q  Vi  or  ipi  C  ip2 

that  intuitively  means  that  the  set  of  program  points  is  included  in  the 
set  ip2  of  program  points.  One  way  to  formalise  this  is  to  say 

3tp'  :  ifii  U  ip'  =  (fi2 

where  we  rely  on  the  axiomatisation  of  “equal  as  sets”  presented  previously. 
Another  way  is  by  means  of  an  explicit  system  of  rules  and  axioms  for  in¬ 
ferring  judgements  of  the  form  <pi  C  we  shall  dispense  with  these  details 
(but  see  Exercise  5.3). 

One  way  to  ensure  that  (Ann,  C)  is  a  complete  lattice  is  to  demand  that 
all  annotations  are  subsets  of  a  given  finite  set;  for  this  one  might  replace 
Pnt  by  the  finite  set  Pnt*  of  program  points  occurring  in  the  expression  of 
interest.  Another  possibility  will  be  to  change  the  syntax  of  annotations  to 
allow  expressing  an  arbitrary  subset  of  Pnt.  Either  approach  works,  since 
all  that  suffices  for  the  subsequent  development  is  to  assume  that: 

(Ann,  C)  is  a  complete  lattice  isomorphic  to  (P(Pnt),  C). 

The  partial  ordering  on  Ann  will  sometimes  be  written  as  C  and  sometimes 
as  C. 

Complete  lattice  of  annotated  types.  We  can  now  extend  the 
partial  ordering  on  annotations  to  operate  on  annotated  types  that  have  the 
same  underlying  type.  For  this  let  r  €  Type  be  a  type  and  write 

Type[r] 

for  the  set  of  annotated  types  f  with  underlying  type  r,  i.e.  such  that  =  r. 
Next  define  ff  C  ?2  for  ?i,?2  €  Type[r]  to  mean  that  whenever  r;  has  the 
annotation  y>i  in  a  given  position  then  tpi  C  ip2-  Formally  this  is  achieved 
by: 

?n9  n  <p  Cip'  t2  c f ' 

?1  -£>■  ?2  C  t{  ?2 

As  an  example,  (int  -^4  int)  -je2>  int  C  (int  -^4  int)  -^4  int  will 
be  the  case  if  and  only  if  ipi  C  ip3  and  C  ip 4.  (Note  that  this  ordering 
is  not  contravariant  unlike  what  will  be  the  case  for  the  subtyping  to  be 
introduced  in  Section  5.4.)  Clearly  the  least  element  in  Type[r]  will  have  0 
on  all  function  arrows  occurring  in  r  and  the  greatest  element  will  have  Pnt 
on  all  function  arrows. 


5.2  Theoretical  Properties 


293 


It  is  straightforward  to  prove  that  each  (Type[r],  C)  is  a  complete  lattice. 
In  a  similar  way  the  partial  ordering  can  be  extended  to  operate  also  on  type 
environments  having  the  same  underlying  structure.  Finally,  suppose  that 
T  h(jL  e  :  r  and  write 

JUDGcfaF  bUL  e  :  r] 

for  the  set  of  typings  f  I~cfa  e  :  f  such  that  [-J  maps  T  I~cfa  c  :  r  to 
T  hut  e  :  t  (and  hence  |_rj  =  T  and  [rj  =  r).  This  facilitates  extending  the 
partial  ordering  C  to  operate  on  the  set  JUDGcfaP  I— ul  e  :  r]  of  typings. 

Moore  family  result.  We  are  now  ready  to  state  the  result  about 
Moore  families: 


Proposition  5.12 

JUDGcfa[F  F(jl  e  :  r]  is  a  Moore  family  whenever  T  1— ul  e  :  r. 


Proof  We  assume  that  P  Kul  e  :  r  and  prove  that  JUDGcfa[F  Hul  e  :  r]  is  a 
Moore  family.  For  this  we  proceed  by  induction  on  the  shape  of  the  inference  tree 
for  T  1— ul  e  :  r.  We  shall  only  give  the  proof  for  the  cases  [var],  [fn]  and  [ app]\  the 
other  cases  follow  the  same  overall  pattern.  In  all  cases  let 

Y  =  {(r  hcFA  e  :  t4)  |  t  £  /} 

be  a  subset  of  JUDGcfa[F  Hul  e  :  r],  -Using  that  (Type[r'j,  C)  is  a  complete  lattice 
for  all  choices  of  r'  €  Type  we  get  that  |”|F  exists  and  that  it  is  defined  in  a 
pointwise  manner.  (Note  that  if  7  =  0  then  (~]F  is  obtained  from  T  I~ul  e  :  r  by 
placing  r)0  =  Pnt  as  annotation  on  all  function  arrows.)  It  remains  to  show  that 
HP  €  JUDGcFA[r  Hul  e  :  r). 

The  case  [war].  The  result  follows  from  (n<r‘)(x)  =  (—j<(P,(a:)). 

The  case  [fn].  We  have  T  frui  fn,  x  =>  eo  :  t*  -¥  To  because  r[x  tx]  Kul  eo  :  to. 
For  i  e  I  we  have  Tl  Hcfa  fn,  x  =>  eo  :  rj  >  tq  because  of 

r’[x  t->  rj]  l-CFA  eo  :  To 

and  clearly  r*[x  i-4  rj]  I-cfa  eo  :  rg  is  an  element  of  JUDGcfa[F[x  *->  rx]  Ful  eo  :  to]. 
By  the  induction  hypothesis  we  get  (f]iF‘)[x  >->■  I”cfa  eo  :  n*^o  and  hence 

l-CFA  fn,  x  =>  eo  :  fl 


where  tp  = 

The  case  [app].  We  now  have  P  t— ul  ei  e2  :  to  because  T  bui  ei  :  T2  — f  to  and 
T  Kul  ei  :  T2.  For  all  i  €  /  we  have  T‘  I~cfa  ei  e2  :  rg  because 
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and  clearly  P  Pcfa  ei  :  ri  is  an  element  of  JUDGcFA[r  Pul  ei  :  ti  -+  ro]  and 

P  Pcfa  e2  :  is  an  element  of  JUDGcfa[F  hut  e2  :  T2].  By  the  induction  hypothesis 
we  get  n<r*  I-  ei  :  (“I;?)  fli^o  and  n«F‘  P  e2  :  where  tp  =  f)i  <p'  and  hence 

n*r‘  P  ei  e2  :  fliTo 

which  is  the  desired  result.  ■ 

Example  5.13  Consider  the  expression  e: 

f  (fnx  x  =>  x+1)  +  f  (fny  y  =>  y+2)  +  (fnz  z  =>  z+3) (4) 

In  the  underlying  type  system  we  have: 

[/  h+  (int  — >  int)  -+  int]  P  e  :  int 
In  the  Control  Flow  Analysis  we  have 

[f  h4  (int  -^4  int)  int]  P  e  :  int 

whenever  {X,Y}  C  ipi.  The  least  solution  therefore  has  <pi  =  {X,Y}  and 
1^2  =  0-  This  clearly  tells  us  that  f  is  only  applied  to  (fnx  x  =>  x+1) 
and  (fny  y  =>  y+2)  and  not  to  (fnz  z  =>  z+3).  A  larger  solution  like 
tpi  =  {X,  Y,  Z}  and  </?2  =  {V}  would  not  convey  this  information.  Hence  it 
seems  sensible  to  ask  for  the  least  solution  with  respect  to  C  and  the  existence 
of  this  solution  is  guaranteed  by  Proposition  5.12.  ■ 


5.3  Inference  Algorithms 

The  main  difference  between  an  analysis  expressed  in  the  form  of  an  inference 
system  (as  in  Table  5.2)  and  in  the  form  of  an  algorithm  is  that  the  user  of 
the  inference  system  is  expected  to  have  sufficient  foresight  to  be  able  to 
guess  the  right  types  and  annotations  whereas  the  implementation  of  the 
algorithm  will  make  use  of  a  mechanism  for  making  tentative  guesses  that 
are  later  refined.  Let  us  first  consider  the  simple  case  corresponding  to  the 
underlying  type  system  of  Table  5.1. 

5.3.1  An  Algorithm  for  the  Underlying  Type  System 

Augmented  types.  The  algorithm  corresponding  to  the  type  system 
of  Table  5.1  will  work  on  augmented  types  that  allow  the  use  of  type  variables 
to  reflect  that  the  details  of  a  type  are  not  fully  determined  yet: 

r  e  AType  augmented  types 
a  £  TVar  type  variables 
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We  shall  take: 

r  int  |  bool  |  T\  — >  r2  |  a 

a  ::=  'a  |  'b  |  'c  |  ••• 


Substitutions.  A  substitution  is  a  finite  and  partial  mapping  from  type 
variables  to  augmented  types,  we  write 

0  :  TVar  -4fin  AType 

and  note  that  the  domain  dom(0)  =  {a  |  6  is  defined  on  a}  is  finite.  We 
shall  allow  to  view  a  substitution  as  a  total  function  from  type  variables  to 
augmented  types,  setting  6  a  =  a  whenever  a  dom(0).  We  shall  say  that 
a  substitution  0  is  defined  on  a  if  and  only  if  a  6  dom(0). 

The  substitution  0  is  called  a  ground  substitution  if  and  only  if  it  maps  all  type 
variables  in  its  domain  to  ordinary  types,  i.e.  if  Va  6  dom(0)  :0a  6  Type. 
The  substitution  0  is  said  to  cover  T,  respectively  r,  if  and  only  if  it  is  defined 
on  all  the  type  variables  in  T,  respectively  r.  Substitutions  can  be  applied  to 
augmented  types  in  a  pointwise  manner: 


0  int  = 
0  bool  = 
0(n  -»  r2)  •:.= 
0  a 


int 

bool 

{0  rx)  -4  (0  r2) 
r  if  0  a  =  t 


We  shall  write  0i  o02  for  the  composition  of  0\  and  02,  i.e.  {6\  o02)r  =  0\  (d-2  r) 
for  all  augmented  types  r. 

The  idea.  The  type  reconstruction  algorithm,  called  Wul,  is  given  two 
arguments:  an  augmented  type  environment  T  (mapping  program  variables 
to  augmented  types)  and  an  expression  e.  If  it  succeeds  in  finding  a  typing 
for  the  expression  then  it  will  return  its  augmented  type  r  and  a  substitution 
0  telling  how  the  type  environment  has  to  be  refined  in  order  to  obtain  a 
typing.  As  an  example  we  will  have 

yVuL([a:  'a],  1  +  (x  2))  =  (int,  ['a  h*  int  -4  int]) 

because  during  the  inspection  of  the  expression  1  +  (x  2)  it  becomes  clear 
that  x  must  be  a  function  from  integers  to  integers  if  the  expression  is  to  be 
correctly  typed.  So  the  idea  is  that  if 

WUL(r,e)  =  (r,0)  then  0G{0  T)  1-ul  e  :  9g  t 

for  every  ground  substitution  0q  that  covers  0  T  and  r,  i.e.  whenever  we 
replace  all  the  type  variables  with  ordinary  types  in  a  consistent  way.  When 
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this  property  holds  we  shall  say  that  the  algorithm  is  syntactically  sound. 
In  order  for  the  algorithm  to  be  syntactically  complete  it  is  also  required 
that  all  typings  obtainable  in  the  inference  system  can  be  reconstructed  from 
the  results  of  the  algorithm.  We  shall  discuss  these  properties  at  length  in 
Subsection  5.3.3. 

The  algorithm.  The  algorithm  Wul  is  specified  in  Table  5.5  and  is  ex¬ 
plained  below.  The  algorithms  asks  for  fresh  type  variables  at  several  places. 
By  this  is  meant  type  variables  that  do  not  occur  in  the  argument  to  Wul 
and  that  have  not  been  generated  as  fresh  variables  elsewhere;  this  could  be 
formalised  by  supplying  Wul  with  yet  another  parameter  for  tracking  the 
type  variables  that  remain  fresh  but  it  is  customary  not  to  do  so.  There  is  a 
small  amount  of  nondeterminism  in  Wul  in  that  there  may  be  many  choices 
for  the  fresh  variables;  this  could  be  made  precise  by  assuming  they  are  all 
numbered  and  by  always  supplying  the  candidate  with  the  smallest  number 
but  again  it  is  customary  not  to  do  so. 

In  the  clause  for  variables  we  simply  note  that  the  type  of  c  is  rc  and  there  is 
no  need  to  adjust  our  assumptions  T  so  we  return  the  identity  substitution 
id:  we  demand  that  id  a  =  a  for  all  a  and  could  take  id  to  be  the  empty 
mapping.  The  clause  for  variables  is  similar  except  that  now  we  consult  the 
type  environment  T  to  determine  the  augmented  type  of  x. 

For  function  abstraction  we  assume  that  the  formal  parameter  has  type  ax 
for  ax  being  a  fresh  type  variable  7-  so  far  we  have  no  constraints  on  the  type 
of  the  formal  parameter.  Then  we  call  Wul  recursively  on  the  function  body 
to  determine  its  type  under  the  assumption  that  x  has  type  ax.  The  resulting 
type  r0  and  substitution  60  are  then  used  to  construct  the  overall  type;  in 
particular,  80  is  used  to  replace  the  type  variable  ax  with  a  more  refined 
type  since  the  analysis  of  the  function  body  may  have  provided  additional 
information  about  the  type  of  the  formal  parameter. 

The  clause  for  recursive  function  definition  is  somewhat  more  complicated. 
It  starts  out  in  a  way  similar  to  the  previous  clause  and  requires  fresh  type 
variables  ax  and  ao  so  that  we  can  supply  augmented  types  ax  ->  ao  and  ax 
for  the  occurrences  of  /  and  x,  respectively,  in  the  analysis  of  the  function 
body.  However,  this  will  result  in  two  possible  types  for  the  function  body: 
one  is  the  type  variable  ao  (modified  by  the  substitution  80  obtained  by 
analysing  the  function  body)  and  the  other  is  the  type  tq  obtained  from  the 
analysis  of  the  function  body.  These  two  types  have  to  be  equal  according  to 
the  rule  [fn]  of  Table  5.1  and  to  ensure  this  we  shall  use  a  unification  procedure 
Wul!  its  definition  will  be  discussed  in  detail  below  but  the  idea  is  that  given 
two  augmented  types  T\  and  T2,  Wul(ti  ,  72)  will  return  a  substitution  8  that 
makes  them  equal  i.e.  such  that  8  Ti  =  8  T2.  In  the  clause  for  recursive 
function  definition  we  get  that  0i(ro)  =  81(80  ao)  so  the  overall  type  will 
be  81  (60  ax)  ->  To-  Also  we  record  that  the  assumptions  of  T  have  to  be 
modified  by  80  as  well  as  9\ . 
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Wui_(r,c)  =  (rc,  id) 

WUL(I»  =  (r(z),  id) 

Wub(r;  fnn  x  =>  eo)  =  let  a*  be  fresh 

(tq,0o)  =  WuL(r[a:  ^  a^J.eo) 
in  ((6o  ax)  -4  To,  0o) 

WuL(r,  fun„-  /  x  =>  e0)  = 

let  ax ,  ao  be  fresh 

(to, So)  =  WUL(r[/  i->  ax  -»  a0][x  h4  ax),eo) 
Si  =  Z4jl(to,0o  Qo) 
in  (0i (So  ax)  -4  0i  r0l  0i  °0O) 

WUL(r,ei  e2)  =  let  (ri,0i)  =  WuL(I\ei) 

(t2,02)  =  Wul(0i  r,e2) 
a  be  fresh 

03  =^ul(02  ti,t2  -*  a) 
in  (03  a,  03°02o0i) 

WuL(r,  if  e0  then  ex  else  e2)  =  let  (ro,0o)  =  WuL(r,e0) 

(ti,0i)  =  WUL(0O  r,ei) 
(t2,02)  =  Wul(0i(0o  r),e2) 

03  =Wul(02(0i  to), bool) 

04  =^ul(03  T2, 03(02  Ti)) 

•  '  in  (04(03  T2),  04  O  03  O  02  O  0j) 

WuL(r, let  x  =  ei  in  e2)  =  let  (ti,0i)  =  WuL(r,ei) 

(t2,02)  =  WUL((0i  T)[*  Ti], e2) 
in  (t2,  02o0j.) 

WuL(r,ei  op  e2)  =  let  (n,0i)  =  WUL(r,ei) 

(t2,02)  =  WUL(0i  r,e2) 

03  =Wul(02  Ti  ,  T^p) 

04  =WUL(03  T2,T2oj>) 
in  (Top,  04  O  03  0  02  O  01 ) 


Table  5.5:  Algorithm  Wul  for  the  underlying  type  system. 


Also  the  clause  for  function  application  relies  on  the  unification  procedure. 
In  this  clause  we  call  Wul  recursively  on  the  operator  and  the  operand  and 
we  use  unification  to  ensure  that  the  type  of  the  operator  ti  (modified  by 
02)  is  a  function  type  with  an  argument  type  that  equals  the  type  t2  of  the 
operand:  02  n  has  to  have  the  form  t2  -4  a.  Again  we  have  to  record  that 
the  assumptions  of  F  have  to  be  modified  by  all  three  substitutions  that  have 
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been  constructed. 

By  now  the  clause  for  conditional  is  straightforward  and  similarly  the  clauses 
for  the  let-construct  and  the  binary  operator.  (Note  that  the  let-construct 
is  not  polymorphic  so  no  special  action  is  needed  to  determine  the  type  of 
the  bound  variable;  we  shall  return  to  the  problem  of  polymorphism  later.) 

Example  5.14  Consider  the  expression  (fnx  x  =>  x)  (fny  y  =>  y)  of 
Example  5.1.  The  call 

Wul([  ],  (fnx  x  =>  x)  (fnY  y  =>  y)) 

gives  rise  to  the  call 

Wul([  ],fnx  x  =>  x) 

which  will  create  the  fresh  type  variable  'a  and  return  the  pair  ('a  -»  'a,  id). 
We  now  have  the  call 

Wul([  ],fny  y  =>  y) 

that  creates  the  fresh  type  variable  'b  and  returns  ('b  — >  'b,  id).  Thus  we  get 
the  following  call  of  Z4jl 

— ►  'a,  (*b  — >  #b)  — >  *c) 

where  'c  is  a  fresh  type  variable.  As  we  shall  see  in  Example  5.15  below  this 
gives  rise  to  the  substitution  ['a  h->  'b  -►  'b]['c  'b  — >•  /b]  and  the  initial  call 
of  Wul  will  return  'b  — >  'b  and  ['a  'b  -»  'b]['c  >-►  'b  -»  'bj.  ■ 

Analogy.  The  placement  of  substitutions  in  Table  5.5  may  seem  ad  hoc 
at  first  sight.  As  an  aid  to  the  intuition  we  shall  therefore  offer  the  following 
analogy.  Consider  a  society  where  a  number  of  laws  have  been  passed.  One 
such  law  might  stipulate  that  when  the  owner  of  a  personal  computer  sells 
it,  the  owner  is  obliged  to  comply  with  the  law  and  in  particular  provide 
the  buyer  with  the  original  disks  for  all  software  that  remains  on  the  com¬ 
puter.  And  let  us  focus  our  attention  on  a  particular  owner  preparing  to  sell 
a  computer  and  who  is  determining  an  acceptable  selling  price.  Then  some 
day  parliament  passes  a  law  stating  that  whenever  original  software  disks  are 
passed  on  from  one  private  person  to  another,  the  previous  owner  has  to  pay 
a  fee  of  ten  percent  of  the  original  buying  price  to  a  government  agency  com¬ 
bating  software  piracy.  From  this  day  on  the  owner  of  the  computer  needs  to 
reconsider  all  the  considerations  made  in  order  to  determine  the  acceptable 
selling  price.  In  short:  whenever  a  new  law  is  passed  all  existing  considera¬ 
tions  need  to  be  reconsidered  in  order  to  remain  valid.  —  Coming  back  to 
Table  5.5,  the  typings  determined  by  Wul  correspond  to  the  considerations 
of  the  owner,  and  the  substitutions  produced  by  Wul  to  the  new  laws  being 
passed  by  parliament:  whenever  a  new  substitution  (“law”)  is  constructed 
all  existing  typings  (“considerations”)  must  be  suitably  modified  so  as  to  re¬ 
main  valid;  this  is  exactly  what  is  achieved  by  the  carefully  chosen  use  of 
substitutions  in  Table  5.5.  □ 
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Z4n.(int,  int) 

=  id 

Uul  (bool, bool) 

=  id 

Z4jl(ti  ->  r2,r{  r^) 

— 

let  6i  =  Z4ji(n,r() 

02  =  Wul(01  Tz,9l  Tj) 
in  Oz  o  6i 

j 

f  [a  i-4  r]  if  a  does  not  occur  in  r 

Z-Ajl  (r,a) 

=  1 

or  if  a  equals  r 
[  fail  otherwise 

1 

|  [aHr]  if  a  does  not  occur  in  r 

Wul  (a,T) 

"i 

or  if  a  equals  r 
[  fail  otherwise 

U\Jl(Tl,Tz) 

=  fail  in  all  other  cases 

Table  5.6:  Unification  of  underlying  types. 


Unification.  The  algorithm  Z4jl  for  unifying  two  augmented  types  is 
shown  in  Table  5.6.  It  takes  two  augmented  types  T\  and  r2  as  arguments 
and  if  it  succeeds  it  returns  a  substitution  6  such  that  0  ri  =  0  t2. 

In  the  clause  for  unifying  the  two  function  types  T\  — ►  r2  and  r[  — ►  r 2  the 
desired  result  is  obtained  in  two  stages:  6\  ensures  that  Q\  t\  =  6\  t[  and 
hence  (02  o^)  n  =  (02  °  9\)  t[  and  02  ensures  that  6z{9\  tz)  =  6z{6\  Tj);  it 
follows  that  6z  °  #i  succeeds  in  unifying  the  two  function  types.  Note  that 
the  algorithm  only  fails  at  top-level  if: 

•  two  types  with  different  top-level  constructors  (by  which  we  mean  int, 
bool,  or  -»)  are  to  be  unified,  or 

•  a  type  variable  is  to  be  unified  with  a  function  type  containing  that 
type  variable. 


Example  5.15  In  Example  5.14  we  had  the  following  call  of  the  unifica¬ 
tion  procedure: 

14 uL^a  — >  fa,  ((b  — >  *b)  — >  'c) 

It  will  first  give  rise  to  the  call  (b  — >  'b)  which  returns  the  substitution 

['a  >->■  'b  — >  'b].  Then  we  will  have  the  callZVui('b  'b,  'c)  and  the  substitution 
['c  'b  -»  'b]  is  returned.  Thus  the  overall  result  will  be  the  substitution 
['a  n->  'b  — >  'b]['c  'b  ->  'b]  as  already  used  in  Example  5.14.  ■ 
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5.3.2  An  Algorithm  for  Control  Flow  Analysis 

In  applying  the  above  ideas  to  the  inference  system  for  Control  Flow  Analysis 
presented  in  Table  5.2  we  are  going  to  face  a  difficulty.  In  the  underlying  type 
system  two  types  are  equal  if  and  only  if  their  syntactic  representations  are 
the  same;  we  say  that  types  constitute  a  free  algebra.  For  annotated  types, 
two  annotated  types  may  be  equal  even  when  their  syntactic  representations 
are  different:  int  int  equals  int  hahlisl  >  int  because 

annotations  and  types  are  considered  equal  modulo  UCAI  as  discussed  in 
Subsection  5.1.2  -  we  say  that  annotated  types  constitute  a  non-free  algebra. 

The  difficulty  we  encounter  when  transferring  the  development  of  the  previous 
subsection  to  the  Control  Flow  Analysis  is  that  the  algorithm  Wul  relies 
on  the  procedure  Wul  for  unifying  two  types,  and  that  this  algorithm  only 
applies  to  types  in  a  free  algebra.  One  way  out  of  this  difficulty  would  be  to 
use  instead  an  algorithm  for  unifying  modulo  UCAI;  such  algorithms  exist 
but  their  properties  are  not  so  nice  as  those  of  Wul-  Another  way  out  of  the 
difficulty,  and  the  approach  we  shall  take,  is  to  arrange  it  such  that  a  variant 
of  Wul  can  still  be  used  by  introducing  additional  mechanisms  for  dealing 
with  the  annotations:  one  is  the  notion  of  simple  types  and  annotations  and 
the  other  is  the  use  of  constraints. 

Simple  types  and  annotations.  The  first  step  will  be  to  restrict 
the  form  of  the  annotated  types  so  that  only  annotation  variables  are  allowed 
on  the  function  arrows;  later  we  shall  combine  this  with  a  set  of  constraints 
restricting  the  values  of  the  annotation  variables. 

A  simple  type  is  an  augmented  annotated  type  where  the  only  annotations 
allowed  on  function  arrows  are  annotation  variables  and  where  type  variables 
are  allowed  in  types,  and  a  simple  annotation  is  an  annotation  where  also 
annotation  variables  are  allowed: 


f 

G 

SType 

simple  types 

a 

G 

TVar 

type  variables 

0 

G 

AVar 

annotation  variables 

V 

G 

SAnn 

simple  annotations 

Formally,  the  syntactic  categories  are  given  by: 

f  ::=  int  |  bool  |  fi  — ►  T2  |  ct 
a  ::=  'a  |  'b  |  'c  |  •  •  • 

0  ::=  'l|'2|'3|--- 

‘ P  ::=  {x}  |  y>i  U  <p2  |  0  |  0 

A  simple  type  environment  T  then  is  a  mapping  from  variables  to  simple 
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i/cFA(int,  int)  =  id 


i/cFA  (bool,  bool)  =  id 


U cfa(?i  A  t2,t[  -A  fj)  =  let  0o  =  [/3'^/3] 

0i  =ZVcfa(0o  ?1)0O  ?l) 

02  =^CFa(01  (00  ^2), 01  (00  ^2)) 
in  02  0  0  0O 


(  [a  h*  f] 

if  a  does  not  occur  in  f 

Z7cfa  (?,<*)  =  1 

or  if  a  equals  f 

{  fail 

otherwise 

(  [ai->  f] 

if  a  does  not  occur  in  f 

74:fa  (o:,r)  =  < 

or  if  a  equals  f 

1  fail 

otherwise 

WcFA^li^h) 


fail  in  all  other  cases 


Table  5.7:  Unification  of  simple  types. 


types. 

Unification  of  simple  types.  Simple  types  constitute  a  free  algebra 
and  so  we  can  apply  the  same  technique  as  in  Subsection  5.3.1  to  define  a 
function  7/cfa  of  the  following  form: 


Ucfa{ti,t2)  =  0 


Here  fj  and  f2  are  simple  types  and  0  will  be  a  simple  substitution:  A  simple 
substitution  is  a  substitution  that  maps  type  variables  to  simple  types,  and 
that  maps  annotation  variables  to  annotation  variables  only.  Thus  a  simple 
substitution  applied  to  a  simple  type  still  gives  a  simple  type.  As  for  Uui 
the  intention  is  that  0  unifies  ?i  and  r2,  i.e.  0  n  =  0  r2.  In  case  this  is  not 
possible  the  outcome  ofZVcFA^i,^)  will  be  a  failure.  The  unification  function 
Wcfa  is  defined  in  Table  5.7  and  is  explained  below. 

As  before  id  is  the  identity  substitution  and  0'  o  0"  is  the  composition  of  two 
substitutions.  In  the  clause  for  unifying  the  two  function  types  ?i  A  t2 
and  t(  -£-»  %  the  desired  result  is  obtained  by  first  ensuring  that  the 

two  annotation  variables  are  equal  and  then  proceeding  as  in  the  unification 
algorithm  for  the  underlying  types.  Note  that  Z7cfa(ti,  t2)  will  fail  if  and  only 
if  74jl(|/tiJ.  L^J)  fails. 
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Example  5.16  Consider  the  following  call  of  the  unification  procedure: 
^CFA('a  — ■»  'a,  ('b  'b)  -A  'c) 

We  construct  the  substitution  ['3  f->  'l]  and  then  we  perform  the  call 

^CFACa, 'b  — >  'b) 

which  returns  the  substitution  ['a  'b  'bj.  Then  we  make  the  call 

Mcfa  ('h  — >  (b,  'c) 

and  the  substitution  ['c  •->  'b  -b  'b]  is  returned.  Thus  the  overall  result  will 
be  ['3  'l]['a  'b  'b]['c  'b  'b],  ■ 

The  following  fact,  whose  proof  we  leave  to  Exercise  5.7,  expresses  that  the 
algorithm  is  correct.  The  first  part  of  the  result  says  that  the  algorithm  is 
syntactically  sound:  if  it  succeeds  then  it  produces  the  desired  result.  The 
second  part  says  that  the  algorithm  is  syntactically  complete:  if  there  is  some 
way  of  unifying  the  two  simple  types  then  the  algorithm  will  succeed  in  doing 
so. 

Fact  5.17  Let  ?i  and  t2  be  two  simple  types. 

•  If  Ucfa(t\  ,  r2)  =  9  then  6  is  a  simple  substitution  such  that  9t\  =  9 r2. 

•  If  there  exists  a  substitution  9"  such  that  9"r\  =  9"t2  then  there  exists 
substitutions  9  and  9'  such  that  WcfaOd,  t2)  =  9  and  9"  =  9'  off.  u 

Constraints.  Annotated  types  can  contain  arbitrary  annotations  and 
simple  types  can  only  contain  annotation  variables.  To  make  up  for  this 
deficiency  we  shall  introduce  constraints  on  the  annotation  variables.  A  con¬ 
straint  is  an  inclusion  of  the  form 

where  (i  is  an  annotation  variable  and  <p  is  a  simple  annotation.  A  constraint 
set  C  is  a  finite  set  of  such  constraints. 

We  shall  write  9  C  for  the  set  of  inclusions  obtained  by  applying  the  substi¬ 
tution  9  to  all  the  individual  constraints  of  C:  if  /?  D  ip  is  in  C  then  9  (3  D  9  <p 
is  in  9  C.  If  C  is  a  constraint  set  and  9  is  a  simple"  substitution  then  also  9  C 
is  a  constraint  set. 

A  type  substitution  is  a  substitution  that  is  defined  on  type  variables  only 
and  that  maps  them  to  types  in  Type  (i.e.  to  annotated  types  without  type 
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and  annotation  variables);  we  shall  say  that  it  covers  T,  respectively  r,  if  it 
is  defined  on  all  type  variables  in  F,  respectively  f.  Similarly,  an  annotation 
substitution  is  a  substitution  that  is  defined  on  annotation  variables  only 
and  that  maps  them  to  annotations  in  Ann  (i.e.  to  annotations  without 
annotation  variables);  it  covers  T,  respectively  r  or  C,  if  it  is  defined  on  all 
annotation  variables  in  T,  respectively  f  or  C.  An  annotation  substitution 
9 a  solves  a  constraint  set  C,  written 

9a\=C 

if  and  only  if  it  covers  C  and  for  each  /3  D  tp  in  C  it  is  the  case  that  6a  P  is 
a  superset  of,  or  is  equal  to,  6a  <P- 

A  ground  substitution  is  an  annotation  substitution  on  annotation  variables 
and  a  type  substitution  on  type  variables.  A  substitution  6  is  a  ground 
validation  of  (r,  f ,  C)  if  and  only  if  it  is  a  ground  substitution  that  covers 
T,  9  and  C  and  such  that  6  (=  C  (or  more  precisely,  6a  \=  C  where  6 a  is  the 
restriction  of  6  to  the  annotation  variables) . 

The  algorithm.  We  are  now  ready  to  define  an  analogue  of  the  type 
reconstruction  algorithm  Wul-  It  has  the  form 

Wcfa(F,  e)  =  (r,6,C) 

where  we  demand  that  T  is  a  simple  type  environment  (i.e.  that  it  maps 
variables  to  simple  types),  and  it  will  be  the  case  that  f  is  a  simple  type,  6  is 
a  simple  substitution,  and  C  is  a  constraint  set  of  a  very  special  form:  it  only 
contains  constraints  of  the  form  /?  D  {a-}.  Since  Wcfa  will  make  use  of  Z/cfa 
there  also  is  the  possibility  that  Wcfa  fails.  The  algorithm  Wcfa  is  defined 
by  the  clauses  of  Table  5.8  and  is  explained  below. 

In  the  clauses  for  constants  and  variables  we  proceed  as  before  and  do  not 
impose  any  constraints.  In  the  case  of  function  abstraction  we  shall  addi¬ 
tionally  use  a  fresh  annotation  variable  (30  ■  it  will  be  the  top-level  annotation 
of  the  overall  type  and  we  shall  add  a  constraint  /%>  2  i71"}  requiring  that 
it  includes  the  label  n  of  the  function  definition  -  this  corresponds  to  the 
annotation  {7r}  U  </?  used  in  the  rule  \fn]  of  Table  5.2. 

The  clause  for  recursive  function  definition  is  modified  in  a  similar  way.  Here 
the  annotation  variable  f3  will  be  used  to  annotate  the  function  type  of  /  and 
the  call  of  Wcfa  on  the  body  of  the  function  may  cause  it  to  be  modified  to 
60  /So-  Next  the  call  of  the  unification  procedure  may  cause  it  to  be  further 
modified  to  6 1  (0O  fh)-  Since  both  6q  and  6\  are  simple  substitutions  we 
know  that  6\  (60  P0)  is  an  annotation  variable  so  the  resulting  type  will  still 
be  simple.  The  recursive  call  of  Wcfa  gives  rise  to  a  constraint  set  Co  that 
has  to  be  modified  using  the  substitution  6i  and  as  in  the  clause  for  ordinary 
function  abstraction  we  have  to  add  a  new  constraint  expressing  that  the 


304 


TYPE  AND  EFFECT  SYSTEMS 


WCFA(f,c)  =  (tc,  id,  0) 

Wcfa(?,x)  =  (P(a;),  id,  0) 

HWr.fn*  x  =>  eo)  =  let  ax  be  fresh 

(ro.^OiCo)  =  VVcFA(r[a:  i->-  ax],e o) 

0o  be  fresh 

in  ((0o  ax)  tq,  $o,  Co  U  {/?o  3  f71"}}) 

WcFA(r,funff  /  x  =>  e0)  = 

let  ax,ao,  0o  be  fresh 

(t0, 6o,  Co)  =  WcFA(f[/  » ->a,  Q0][x  ►->  ax ],e0) 

0i  =  Mcfa(to,  0o  Qo) 

in  (0i(0o  ax)  f0)  0!  o  0O) 

(0i  Co)U{01(0o  A)  2  M» 

WcFA(r,ei  e2)  =  let  (t\,0\,Ci)  =  Wcfa(F,ci) 

(T2,02,C2)  =  Wcfa(01  r,e2) 
a,0  be  fresh 

03  =  Wcfa  (02  ti,t2  -A  q) 
in  (03  a,  03  o  02  o  0i ,  03  (02  Ci)  U  03  C2) 

WCFA(r,  if  e0  then  ei  else  62)  = 

let  (ro,0o,Co)  =  WGFA(r,eo) 

(n,0i,C1)  =  Wcfa(0o  r,ei) 

(T2,02,C2)  =  VVcFA (01  (00  r),e2) 

03  =^CFa(02  (01  To),  bool) 

04  =^CFA(03  T2,03  (02  Ti)) 
in  (04  (03  r2),  04  O  03  o  02  o  0!  o  0O, 

04  (03  (02  (01  Co)))U04  (03  (02  C'1))U04  (03  C2)) 
WcFA(r,  let  x  =  ei  in  e2)  = 

let  (ti  ,  0i ,  Ci )  =  Wcfa  (P,  ei) 

(r2,02,C2)  =  Wcfa((0i  f)[x  h*  ri],e2) 
in  (t2,  02°0i,  (02  Ci)  U  C2) 

WCFA(r\ei  op  e2)  =  let  (ji,Oi,C\)  =  WcFA(r,ei) 

(t2,02,C2)  =  Wcfa(0i  r,e2) 

03  =  Wcfa (02  n  ,rlp) 

04  =  Wcfa (03  t2,t%p) 

in  (Top,  04  0  03  0  02  0  0!, 

04  (03  (02  C'i))U04  (03  C2)) 


Table  5.8:  Algorithm  Wcfa  for  Control  Flow  Analysis. 
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annotation  variable  6\  (do  0o)  has  to  contain  the  label  ir  of  the  function 
definition. 

The  clauses  for  the  remaining  constructs  are  fairly  straightforward  modifica¬ 
tions  of  the  similar  clauses  for  Wul-  Note  that  the  substitutions  are  applied 
to  the  constraint  sets  as  well  as  the  types  and  type  environments. 

Example  5.18  Returning  to  the  expression  (fnx  x  =>  x)  (fny  y  =>  y)  of 
Example  5.1  we  shall  now  consider  the  call: 

WCfa([  ],  (fnx  x  =>  x)  (fny  y  =>  y)) 

It  gives  rise  to  the  call  Wcfa([  ]i  fnx  x  =>  x)  which  creates  a  fresh  type  variable 
'a  and  a  fresh  annotation  variable  '1  and  returns  ('a  -4  'a,  id,  {'12  {X}}). 
Then  we  have  the  call  Wcfa([  ],  fny  y  =>  y)  that  creates  a  fresh  type  variable 
'b  and  a  fresh  annotation  variable  '2  and  returns  ('b  —4  'b,id,  {'2  D  {V}}). 
Thus  we  get  the  following  call  of  Uqfa 

^CFA^a  — >  'a,  ('b  — ►  'b)  — >  'c) 

where  'c  is  a  fresh  type  variable  and  '3  is  a  fresh  annotation  variable.  This 
gives  rise  to  ['3  f->  'l]['a  f-»  'b  -4  'b]['c  •->  'b  -4  'b]  as  shown  in  Example  5.16 
and  the  initial  call  of  Wcfa  will  return  the  type  'b  -4  'b,  the  substitution 
['3  -+  'l]['a  fV  b  -4  'b]['c  'b  4.  'b]  and  the  set  {'1  D  {X}/2  D  {V}}  of 
constraints.  This  corresponds  to  the  typing  obtained  in  Example  5.4.  ■ 

Example  5.19  Consider  the  program  loop 

let  g  =  (funp  f  x  =>  f  (fny  y  =>  y)) 
in  g  (fnz  z  =>  z) 

of  Example  5.2  and  the  call  Wcfa([  ],  loop).  This  will  first  give  rise  to  a  call 
WCfa([  ],funF  f  x  =>  f  (fny  y  =>  y)) 

that  returns  the  type  ('a  -4  'a)  -4  'b  and  the  set  {'1  3  {F} , '2  D  {Y}}  of 
constraints.  Then  we  have  a  call  of  Wcfa  on  the  body  of  the  let-construct: 

WcFA([g  ('a  -A  'a)  -4  'b]>g  (fnz  z  =>  z)) 

The  call  of  Wcfa  on  fnz  z  =>  z  will  give  the  type  'c  —4  'c  and  the  constraint 
set  {'3  D  {Z}}.  The  unification  procedure  will  then  be  called  with  the  types 
('a  -4  'a)  —4  'b  and  ('c  -4  'c)  -4  'd  and  the  resulting  substition  is 
['2  t-*  '3, 'a  t-4  'c,'b  t-4  'd].  Thus  the  application  will  have  type 'd  and  the 
constraint  set  will  be  {'3  2  {Z}}.  The  initial  call  of  Wcfa  on  loop  returns 
the  type 'd  and  the  constraint  set  {'1  2  {F},  '3  2  {Y}, '3  2  {Z}}.  This 
corresponds  to  the  typing  obtained  in  Example  5.5.  ■ 
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As  illustrated  in  the  above  examples,  when  the  overall  call  of  Wcfa(I\  e)  gives 
(?,  9,  C)  we  are  only  interested  in  the  effect  of  9  on  the  type  and  annotation 
variables  occurring  in  T. 

5.3.3  Syntactic  Soundness  and  Completeness 

We  are  now  ready  to  prove  the  correctness  of  the  algorithm;  this  will  take 
the  form  of  a  syntactic  soundness  result  and  a  syntactic  completeness  result. 
Syntactic  soundness  is  a  rather  straightforward  result  to  prove.  This  nor¬ 
mally  also  holds  for  Type  and  Effect  Systems  that  are  more  complex  than 
the  Control  Flow  Analysis  considered  here,  although  the  actual  details  of 
the  Type  and  Effect  Systems  may  of  course  require  special  treatment  going 
beyond  the  techniques  covered  here. 

By  contrast,  syntactic  completeness  is  a  somewhat  harder  result  to  prove. 
For  a  complex  Type  and  Effect  System  it  frequently  involves  establishing 
a  result  about  proof  normalisation:  that  the  non  syntax  directed  rules  of 
the  inference  system  need  only  be  used  at  certain  places  (see  Exercise  5.12). 
However,  in  the  case  of  Control  Flow  Analysis  the  proof  is  going  to  be  un¬ 
characteristically  simple  because  both  the  algorithm  Wcfa  and  the  inference 
system  for  Control  Flow  Analysis  are  defined  in  syntax  directed  ways.  Thus 
the  present  development  does  not  indicate  the  breath  of  techniques  needed 
for  Type  and  Effect  Systems  in  general  and  the  the  Concluding  Remarks  will 
contain  references  to  the  more  gefieral  situation. 

Syntactic  soundness.  The  soundness  result  expresses  that  any  infor¬ 
mation  obtained  from  the  algorithm  is  indeed  correct  with  respect  the  the 
inference  system: 


Theorem  5.20 

If  Wcfa(T,  e)  =  ( t,0,C )  and  9g  is  a  ground  validation  of  9  T,  t 
and  C  then  9q{9  T)  I-cfa  e  :6g  t. 


This  theorem  may  be  reformulated  as  follows:  if  WcfaCT,  e)  =  (f  ,9,C)  and 
Ot  is  a  type  substitution  that^  covers  9  T  and  r,  and  if  9 a  is  an  annota¬ 
tion  substition  that  covers  9  T,  r  and  C  and  that  satisfies  9a  (=  C,  then 
9a(9t(9  T))  bcFA  e  :  9a{9t  t).  To  see  this  first  note  that  9a°9t  =  9t°  9a 
is  a  ground  substitution;  next  note  that  given  a  ground  substitution  9q  we 
may  obtain  an  annotation  substitution  9a  by  restricting  9q  to  annotation 
variables  and  similarly  we  may  obtain  a  type  substitution  9t  by  restricting 
9q  to  type  variables  and  clearly  9 a  =  9a°9t~9t°9a- 

Proof  The  proof  proceeds  by  structural  induction  on  e  (because  Wcfa  is  defined 
by  structural  induction  on  e). 
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The  case  c.  We  have  Wcfa(I\c)  =  (rc,  id,  0).  Next  let  Qg  be  a  ground  validation  of 
T;  clearly  it  also  covers  tc  (because  rc  is  a  base  type)  and  it  also  satisfies  0g  (=  0. 
Prom  the  axiom  [con]  of  Table  5.2  it  is  immediate  that 

0c(r)  h cfa  c  :  Tc 

and  since  0g  tc  =  rc  this  is  the  desired  result. 

The  case  x.  We  have  Wcfa(P,  x)  =  (r(z),  id,  0).  Next  let  6g  be  a  ground  validation 
of  V;  clearly  it  also  covers  r(x)  and  it  satisfies  9g  (=  0-  Prom  the  axiom  [var]  of 
Table  5.2  it  is  immediate  that 

9g  P  Hcfa  x  :  9g(T(x)) 

and  this  is  the  desired  result. 

The  case  fn*  x  =>  eo-  We  shall  use  the  notation  established  in  the  clause  for 
WCFA(r,fn.  x  =>  eo).  So  let  9g  be  a  ground  validation  of  9o  P,  9o  ctx  -^4  fo,  and 
Co  U  {0o  2  {tr}}-  Then  8q  is  a  ground  validation  of  0o(r[x  a,]),  fo,  Find  Co. 
Hence  by  the  induction  hypothesis  we  get: 

9g{9o  P)[x  t-4  9g(9o  a*)]  I-cfa  eo  :  9g  to 

Since  0g  [=  Co  U  {0o  2  {tt}}  we  have  9a  0a  2  {f  }  so  we  can  apply  the  rule  [fn]  of 
Table  5.2  and  get 

9g{9o  T)  he  fa  fn*  x  =>  eo  :  9g(9o  ax)  — — — >  9g  to 


which  is  the  desired  result. 

The  case  fun*  f  x  =>  eo.  We  shall  use  the  notation  already  established  in  the 
clause  for  Wcfa(P,  fun*  f  x  =>  eo).  So  let  9g  be  a  ground  validation  of  9\  (80  T), 
9i(90  ax)  9X  f0,  and  (0i  C0)  U  {0i(0o  0o)  2  {*}}•  Then  9G  °  0i  is  a 

ground  validation  of  90  P,  0O  ax  f0  and  Co-  Since  0i  to  =  9i(Qo  c*o)  by  Fact 

5.17  we  also  have  that  Qg  °  0i  is  a  ground  validation  of  9o  T,  8o  ax  9°  9o  «o 
and  Co-  Hence  we  can  apply  the  induction  hypothesis  and  get: 

9g{9\{9o  (r[/  •->  Ox  -^4  <*o][x  M-  Q*])))  1*cfa  eo  :  9g{9\  t0 ) 

Since  0i  fo  =  0i(0o  «o)  and0G  [=  (0i  Co)U{0i(0o  0o)  2  {tr}}  we  get  0g(0i(0o  0a))  2 
{«■}  so  we  can  apply  the  rule  [/tin]  of  Table  5.2  and  get 

9g{9\(9q  T))  hcFA  fun*  /  x  =>  eo  :  0g(0i(0o  ax))  g(  l(  0  0G(0i  to) 

and  this  is  the  desired  result. 

The  case  ei  e-i-  We  shall  use  the  notation  already  established  in  the  clause  for 
VVcFA(P,ei  e2).  So  let  Qg  be  a  ground  validation  of  03(02(0i  P))  and  83  a  and 
03  (02  Ci)  U  03  C2.  Let  8'g  be  a  ground  extension  of  0g  upon  03(02  fi)  and  83  T2. 
Then  9'a  °  03  o  83  is  a  ground  validation  of  0i  T,  fi  and  Ci.  Hence  we  can  apply 
the  induction  hypothesis  to  ei  and  get: 

0g(03(02(0i  P)))  1“cfa  ei  :  0g(#3(02  n)) 
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Similarly  0'ao03  is  a  ground  validation  of  82(81  T),  ?2  and  C2.  Hence  we  can  apply 
the  induction  hypothesis  to  e2  and  get: 

80(83(82(61  T)))  Fcfa  e.2  :  60(83  T2) 

Since  63(62  n)  =  (83  T2)  -3  ?->  (83  a)  follows  from  Fact  5.17  we  can  use  the  rule 
[app]  of  Table  5.2  and  get 

60(83(62(61  T)))  Fcfa  e 2  :  80(83  a) 

which  is  equivalent  to  80(63(82(81  T)))  Fcfa  ei  e2  :  60(83  a)  and  this  is  the  desired 
result. 

The  cases  if  eo  then  ei  else  e2,  let  x  =  e\  in  e2  and  ei  op  e2  are  analogous.  ■ 

Syntactic  completeness.  It  is  not  enough  to  show  that  Wcfa  is  syn¬ 
tactically  sound:  an  algorithm  that  always  fails  will  indeed  be  a  syntactically 
sound  implementation  of  our  analysis.  We  shall  therefore  be  interested  in  a 
result  saying  that  any  judgement  of  the  Annotated  Type  System  can  in  fact 
be  obtained  by  the  algorithm: 


Theorem  5.21 

Assume  that  V  is  a  simple  type  environment  and  9'  F  Fcfa  e  :  ?' 
holds  for  some  ground  substitution  6'  that  covers  T.  Then  there 
exists  r,  8,  C  and  do  such  that 

•  WCFA(f  ,e)  =  (r,8,C), 

•  9q  is  a  ground  validation  of  8  F,  r  and  C, 

•  8qo8  —  8'  except  on  fresh  type  and  annotation  variables  (as 
created  by  WcfaT,  e)),  and 

•  9g  t  =  f1. 


Proof  The  proof  is  by  induction  on  the  shape  of  the  inference  tree;  since  the 
Annotated  Type  System  of  Table  5.2  is  syntax  directed  this  means  that  the  proof 
follows  the  syntactic  structure  of  e.  Without  loss  of  generality  we  may  assume  that 
8'  is  not  defined  on  type  and  annotation  variables  that  axe  freshly  generated  in  the 
call  WcFA(r,e). 

The  case  c.  We  have  8'  T  Fcfa  c  :  r'  and  r'  =  rc.  Clearly  WcfaCT,  c)  =  (rc,  id,  0)  so 
it  suffices  to  set  6g  =  8'  and  clearly  8gt'—'?. 

The  case  x.  We  have  8 '  F  Fcfa  x  :  f'  because  t1  =  6'(T(x)).  Clearly  Wcfa(I\x)  = 
(r(x),id,  0)  so  it  suffices  to  set  8g  =  8'. 

The  case  fn*  x  =>  eo-  We  have 
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where  ip'  is  an  annotation  (i.e.  it  does  not  contain  any  annotation  variables)  and 
from  Table  5.2  we  get  that  also: 

{O'  r)[ar  i-4  fx]  hcFA  eo  :  % 

Let  now  ax  be  a  fresh  type  variable  and  note  that  az  dom{6').  Define  0"  by 

a"  (  _  /  %  if  C  =  a* 

’  |  O'  £  otherwise 

where  £  can  either  be  a  type  variable  or  an  annotation  variable.  Then  we  also  have: 

0”{T[x  >-+■  ax])  hcFA  eo  :  ?0 

By  the  induction  hypothesis  there  exists  ro,  0o,  Co  and  0'G  such  that: 

WcFA(r[a;  *-»■  a*],eo)  =  (ro,0o,Co), 

9'c  is  a  ground  validation  of  (0q  T)[r  So(fti)], to,  and  Co, 

0'G  o  60  =  6"  except  on  fresh  type  and  annotation  variables 
created  by  WcFA(r[x  >->  ai],eo) 

0'g  To  =  To 

Next  let  po  be  a  fresh  annotation  variable  and  define: 

*  _  f  M  u  <p'  if  C  =  Po 

^  \  O'g  C  otherwise 

Then  we  get: 

0g  is  a  ground  validation  of  0O  T,  {0o  ax)  -^4  fa  and  Co  U  {0  D  {70} }, 

0g  060  —  O'  except  on  fresh  type  and  annotation  variables 
created  by  WcFA(r,  fn„  x  =>  eo), 

0g(0 0  otx  -&4  ro)  =  fx  >  ?q 

This  is  the  desired  result. 

The  case  fun,  f  x  =>  eo-  We  have 

0  r  i~cfa  fun,/!  =>  e0  :  rx  - >  t0 

where  < p'  does  not  contain  annotation  variables  and  according  to  Table  5.2  this  is 
because: 

{O'  T)[/  h-f  fx  ■  %  r'][x  1-4  1-CFA  eo  :  f0 

Let  ax,  ao  and  0o  be  fresh  type  and  annotation  variables  and  note  that  they  axe 
not  in  dom{0').  Define  9 "  by: 

if  C  =  “1 
if  C  =  Po 
if  C  =  ao 

otherwise 


6”  C  =  < 


{7r}  U  ip' 
TO 

O'  C 


» 


310 


TYPE  AND  EFFECT  SYSTEMS 


Then  we  also  have: 


6"(r[f  •-+  ax  -4  ao][a:  *-4  a*])  Fcfa  eo  :  ?o 

By  the  induction  hypothesis  there  exists  r0,  9o,  Co  and  9'a  such  that: 

VWCFA(r[/  ax  -4  ao][x  (-4  a*],  eo)  —  (fo,  90,  Co) 

6'g  is  a  ground  validation  of  0o(r[/  *-4  ax  -4  q0][x  >-4  ax]),  to,  and  Co 
6'G  o  9o  —  9"  except  on  fresh  type  and  annotation  variables 
created  by  Wcfa(-  •  • ,  eo) 

9'a  fo  =  % 

Since  9'a(9o  ao)  =  9"  <*o  =  To  =  9'G  to  it  follows  from  Fact  5.17  that  there  exists  9i 
and  9g  such  that  Z7cfa  (9o  oco,  to)  =  9\  and  0'G  =  9g  °  9i.  Hence 

9g  is  a  ground  validation  of  9\{9o  r),0i((?o  ax)  9i  t0, 

and  (9i  Co)  U  {9i(9oj3o)  3  {t-}} 

9g  o  9\  o  9o  =  9’  except  on  fresh  type  and  annotation  variables 
created  by  Wcfa(-  •  • ,  fun*  /  x  =>  eo) 

9g{9,{90  ax)  9l^0  a0))=Z  ^4  ?0 

and  this  is  the  desired  result. 

The  case  ei  eo-  We  have 

9f  T  Fcfa  ei  ei  :  r0 

and  according  to  Table  5.2  this  is  because: 


9‘  f  hcFA  ci  :  3  -4  % 

9'  P  hcFA  e-i  : 

By  the  induction  hypothesis  applied  to  e\  there  exists  n,  9i,  Ci  and  0G  such  that: 

WCFA(r,ei)  =  ( Ti,9\,C\ ) 

9g  is  a  ground  validation  of  9\  T,  t)  ,  and  C\ 

9q  o  9 1  =  9'  except  on  fresh  type  and  annotation  variables 
created  by  Wcfa  [O'  I\ei) 

9h  n  =  5J  -4  55 


Then  we  have 

9h(9i  r)  hcFA  e2  :  % 

so  by  the  induction  hypothesis  applied  to  e2  there  exists  ?2,  62,  C2  and  9G  such 
that: 

Wcfa(^i  r,e2)  =  (t2,  9%j  C2) 

9q  is  a  ground  validation  of  82(81  r),T2  and  C2 
9q  o  82  =  Oh  except  on  fresh  type  and  annotation  variables 
created  by  Wcfa(-  --,62) 


OcsT 2=T2 
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It  then  follows  that: 

6%  is  a  ground  validation  of  62(61  r),  #2  n,6 2  Ci , r2 ,  and  C2 
&a  o  62  o  di  =  S'  except  on  fresh  type  and  annotation  variables 
created  by  Wcfa(-  •  • , ei)  and  Wcfa(-  •  • , e2) 

6g(& 2  Ti)  =  ?2  -2-t  To 
6l  r2  =  ?2 

Next  let  a  and  0  be  fresh  and  define: 

(  %  if  C  =  a 

«cC=  ¥>'  if  C  =  /? 

l.  0%  £  otherwise 

Since  60(62  n)  =  60(62  n)  =  tJ  -£-4  tq  =  6%  ?2  -^-4  rj  =  &g(t2  -£4  a)  it  follows 
from  Fact  5.17  that  there  exists  63  and  6q  such  that  Wcfa(#2  ti,  t2  -A  a)  =  @3  and 
6 a  —  6g  0  63 .  It  follows  that 

6g  is  a  ground  validation  of  63(62(61  r)),  63  a,  and  63(62  Ci)  U  63  C2 
&g  o  63  o  62  o  61  =  6'  except  on  fresh  type  and  annotation  variables 
created  by  Wcfa(-  •  • ,  ei  e2) 

60(63  &)  =  6%  a  =  To 

and  this  is  the  desired  result. 

The  cases  if  eo  then  ei  else  e2)  let  x  -  ei  in  e2  and  ei  op  e2  are  analogous.  ■ 


5.3.4  Existence  of  Solutions 

Since  Wcfa  generates  a  set  of  constraints  the  statement  of  syntactic  soundness 
(Theorem  5.20)  is  a  little  weaker  than  usual:  if  the  constraints  cannot  be 
solved  then  we  cannot  use  the  soundness  result  to  guarantee  that  the  result 
produced  by  Wcfa  can  be  inferred  in  the  inference  system. 

This  suggests  showing  that  the  constraints  always  have  solutions;  in  line  with 
previous  developments  in  this  book  we  shall  prove  a  stronger  result.  For  this 
let  AV(C)  be  the  set  of  annotation  variables  in  C. 

Lemma  5.22  If  Wcfa(F,  e)  =  (f,  6 ,  C)  and  X  is  a  finite  set  of  annotation 
variables  such  that  X  D  AV(C),  then 

{6a  I  6a  |=  C  A  dom(6A)  =  X  A  6a  is  an  annotation  substitution} 

is  a  Moore  family.  ■ 

Proof  Let  C  be  a  finite  set  of  constraints  of  the  form  0  D  <p  where  ip  €  SAnn 
and  such  that  X  3  AV(C)  where  A  is  a  finite  set  of  annotation  variables;  it  will 
not  be  of  importance  that  C  is  generated  by  Wcfa-  Let  Y  be  a  possibly  empty 
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subset  of  the  set  displayed  in  the  lemma.  Each  element  of  Y  will  be  an  annotation 
substitution  with  domain  X  and  that  satisfies  C.  By  setting 

9  0  =  C )  (8a  0)  for  0  e  x 

i  ieAeY 

we  define  an  annotation  substitution  6  with  dom(9)  =  X.  For  each  0  D  <p  in  C  and 
6  a  in  Y  we  have 

9  a  0  2  p  5  9  p 

(since  p  is  monotone  in  any  free  annotation  variables)  and  hence: 

This  establishes  the  result.  ■ 

Consider  now  the  call  WcFA(I\e)  =  (r,  9,  C)  and  the  problem  of  finding  a 
ground  substitution  9a  that  covers  OF,?  and  C.  After  the  statement  of 
Theorem  5.20  we  made  it  clear  that  9q  always  can  be  written  9  a0  9t  for 
an  annotation  substitution  9a  covering  9  T,  t  and  C  and  a  type  substitution 
9t  covering  9  T  and  f.  The  choice  of  the  type  substitution  By  must  be 
performed  by  the  user^of  Wcfa;  one  possibility  is  to  let  By  a  =  int  for  all 
type  variables  a  in  9  T  and  f.  The  existence  of  an  annotation  substitution 
9a  now  follows  from  Lemma  5.22. 

Corollary  5.23  If  WcfaCT,  e)  =  ( r,9,C )  then  there  exists  a  ground  val¬ 
idation  9g  of  9  T,  f  and  C.  ■' .  ■ 

Proof  Let  0t  be  given  by  6t  a  ~  int  for  all  type  variables  a  in  9  T  and  f;  clearly 
9t  covers  6  F  and  r.  Next  let  X  be  the  set  of  annotation  variables  in  9  V,r  and  C; 
then  Lemma  5.22  guarantees  the  existence  of  an  annotation  substitution  9 a  that 
covers  9  F,  r  and  C  and  such  that  9a  )=  C.  Taking  9g  —  9a  o  9t  we  obtain  a 
ground  validation  of  9  T,  r  and  C.  m 


The  result  obtained  by  choosing  a  type  substitution  is  only  unique  in  case 
there  are  no  type  variables  present  in  9  T  and  f.  If  there  is  at  least  one 
type  variable  present  then  the  result  of  using  9y  displayed  above  will  differ 
from  the  result  of  using  0'T  given  by  6'T  a  =  bool  for  all  type  variables  a 
in  9  T  and  r.  In  general  a  type  substitution  9y  may  have  9y  a  e  Type[rQ] 
for  an  arbitrary  underlying  type  tq.  However,  in  case  Type[ra]  has  more 
than  one  element  one  is  likely  to  prefer  the  least  element  since  it  has  empty 
annotations  on  all  function  arrows  (but  see  Exercise  5.8). 


In  a  similar  way  one  is  likely  to  prefer  the  least  annotation  substitution 
guaranteed  by  Lemma  5.22.  Keeping  in  mind  that  all  constraints  in  C  have 
the  form  0  D  {7r}  for  0  €  AVar  and  tt  S  Pnt,  we  simply  set: 


0A  0  = 


{ 


{^1/3  2  {?r}  is  in  C) 

undefined 


if  0  e  AV(C) 
otherwise 
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It  is  immediate  that  dom(0A )  =  AV(C)  and  that  0a  1=  C.  If  also  dom(6)  = 
AV(C)  and  6  [=  C  then  it  is  immediate  that  V/3  :  0  /3  D  9a  /3  which  we  may 
write  as  6  □  6a-  This  shows  that  6 a  as  constructed  above  is  indeed  the  least 
element  of  the  Moore  family  displayed  in  Lemma  5.22. 


5.4  Effects 

The  Type  and  Effect  System  for  Control  Flow  Analysis  is  fairly  simple:  it  is 
a  syntax  directed  system  using  a  form  of  subeffecting  and  the  annotations  are 
just  sets.  Much  more  powerful  Type  and  Effect  Systems  can  be  constructed 
by  allowing  subtyping,  let-polymorphism  or  polymorphic  recursion;  the  re¬ 
sulting  analyses  will  be  more  powerful  and,  not  surprisingly,  the  techniques 
required  for  the  implementation  will  be  more  demanding. 

Subtyping  and  the  various  notions  of  polymorphism  can  be  combined  but  for 
the  sake  of  simplicity  we  shall  present  them  one  at  a  time.  We  shall  first 
present  a  Side  Effect  Analysis  for  an  extension  of  the  Fun  language  with 
assignments;  it  will  use  subeffecting  and  subtyping.  Then  we  shall  present 
an  Exception  Analysis  for  an  extension  of  Fun  with  exceptions;  it  will  use 
subeffecting,  subtyping  as  well  as  polymorphism.  Finally,  we  shall  present 
a  Region  Analysis  for  the  Fun  language;  it  will  be  based  on  polymorphic 
recursion. 


5.4.1  Side  Effect  Analysis 

Syntax.  Let  us  consider  an  extension  of  the  language  Fun  (Section  5.1) 
with  imperative  constructs  for  creating  reference  variables  and  for  accessing 
and  updating  their  values: 

e  ::=•••  |  new*  r  :=  ej  in  e2  |  !r  |  r  :=  e0  |  e\  ;  e2 

The  idea  is  that  new*  r :  =  e \  in  e2  creates  a  new  reference  variable  called  r 
and  initialises  it  to  the  value  of  e\  \  the  scope  of  the  reference  variable  is  e2  but 
we  shall  want  the  creation  of  the  reference  variable  to  be  visible  also  outside 
its  scope  so  as  to  be  able  to  determine  whether  or  not  functions  may  need 
to  allocate  additional  memory.  The  value  of  the  reference  variable  r  can  be 
obtained  by  writing  !  r  and  it  may  be  set  to  a  new  value  by  the  assignment 
r  :=  eo.  The  sequencing  construct  ei  ;  e2  first  evaluates  ej  (for  its  side 
effects)  and  then  e2. 


Example  5.24  The  following  program  computes  the  Fibonacci  number 
of  a  positive  number  x  and  leaves  the  result  in  the  reference  variable  r: 
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ne»R  r : =0 

in  let  fib  =  funp  f  z  =>  if  z<3  then  r:  =  !r+l 

else  f(z-l);  f(z-2) 

in  fib  x;  !r 

The  program  creates  a  new  reference  variable  r  and  initialises  it  to  0,  then  it 
defines  the  function  fib,  applies  it  to  the  value  of  x  and  returns  the  value  of  r. 
The  statement  r:  =  !r+l  in  the  body  of  the  recursive  function  will  increment 
the  value  of  r  each  time  it  is  executed  and  each  call  of  fib  x  will  increase 
the  value  of  r  with  the  Fibonacci  number  of  x.  ■ 

The  aim  of  the  Side  Effect  Analysis  is  to  record: 

For  each  subexpression  which  locations  have  been  created,  ac¬ 
cessed  and  assigned. 

So  for  the  function  fib  in  Example  5.24  the  analysis  will  record  that  it 
accesses  and  assigns  the  reference  variable  created  at  program  point  R. 

Semantics.  Before  presenting  the  analysis  let  us  briefly  sketch  the  se¬ 
mantics  of  the  language.  To  distinguish  between  the  various  incarnations 
of  the  new-construct  we  shall  introduce  locations  (or  references)  and,  as  for 
the  imperative  languages  of  Chapter  2,  the  configurations  will  then  contain 
a  store  component  mapping  locations  to  their  values: 

C  €  Store  =  Loc  -►fin  Val 

The  values  of  Val  include  the  constants  c,  the  (closed)  function  abstractions 
of  the  form  fn*  x  =>  e  and  the  locations  £  €  Loc.  The  semantic  clauses  of 
Table  5.4  are  now  modified  to  trace  the  store  as  for  example  in  the  following 
clause  for  the  let-construct: 

P  (ei,<u)  — >  («i,ft)  P  (e2[x  >-►  wi],<a)  — >■ 

P  (let  x  =  ei  in  e2,?i)  — ►  (u2,<r3) 

For  the  new  constructs  we  then  have  the  following  axioms  and  rules  (explained 
below): 

P  (ei,Ci)  — >  (ui,<r2)  P  (e2[r  >->  m])  — »  (v2, ft) 

P  (new*  r  :=  ex  in  e2,ci)  — »  (u2,<r3) 
where  £  does  not  occur  in  the  domain  of  <r2 

P  (!£,?>  — ►  (c(0.«) 

P  (e,Ti)  — »  (u,«T2) 

P  (^:=e,<Ti)  — >  («,<&[?  «]) 

P  (giVTi)  — »  («i,C2)  P  (e2,ft)  — >  (u2,<r3) 

P  (ei;e2,e)  — ►  fa,**) 
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In  the  rule  for  new  we  evaluate  e\ ,  create  a  new  location  £  which  is  initialised 
to  the  value  of  e\,  and  then  we  syntactically  replace  all  occurrences  of  r 
with  that  location  so  that  all  subsequent  references  to  r  will  be  to  £.  We 
exploit  this  when  defining  the  semantics  for  the  constructs  for  accessing  and 
updating  the  reference.  Note  that  the  value  returned  by  the  assignment  will 
be  the  value  being  assigned. 

Annotated  types.  In  the  Side  Effect  Analysis  a  location  will  be  rep¬ 
resented  by  the  program  point  where  it  could  be  created.  We  shall  therefore 
define  the  annotations  (of  effects)  tp  £  AnnsE  by: 

ip  ::=  { ! 7r}  |  {7T :  =}  |  {new?r}  |  tpi  U  ip2  |  0 

The  annotation  !  7r  means  that  the  value  of  a  location  created  at  n  is  accessed, 
tt:=  means  that  a  location  created  at  ir  is  assigned,  and  new7r  that  a  new 
location  has  been  created  at  tt.  As  for  the  Control  Flow  Analysis  we  shall 
consider  annotations  equal  modulo  UCAI. 

The  annotated  types  f  £  TypeSE  are  now  given  by: 

r  ::=  int  |  bool  |  n  %  |  ref*  r 

Here  ref*  f  is  the  type  of  a  location  created  at  the  program  point  n  that 
will  contain  values  of  the  annotated  type  f.  As  before  the  type  environment 
T  will  map  variables  to  annotated -types. 

Example  5.25  Consider  the  Fibonacci  program 

newR  r  :=0 

in  let  fib  =  funp  f  z  =>  if  z<3  then  r:  =  !r+l 

else  f(z-l);  f(z-2) 

in  fib  x;  !r 

of  Example  5.24.  The  variable  r  has  the  annotated  type  ref  r  int  and  the 
variable  fib  has  type  int  '  J)  int  since  it  maps  integers  to  integers 
and  whenever  executed  it  may,  as  a  side  effect,  access  and  update  a  reference 
created  at  the  program  point  R.  ■ 

Typing  judgements.  The  typing  judgements  for  the  Side  Effect  Anal¬ 
ysis  will  be  of  the  form: 

T  I  se  e-.rk.ip 

The  idea  is  that  under  the  assumption  T,  the  expression  e  will  evaluate  into  a 
value  with  the  annotated  type  r  and  that  during  computation  the  side  effects 
expressed  by  might  take  place.  The  analysis  is  specified  by  the  axioms  and 
rules  of  Table  5.9. 
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[con] 

[war] 

\M 

[fun] 

[a PP] 


[let] 

[op] 

[derej] 

[ass] 

[new] 

[seg] 

[su6] 


f  hsE  c  :  tc  k  0 

f  Fse  X  :  f  k  0  if  f  (a)  =  f 

P[z  >-»  %]  FSe  e0  :  f0  &  p0 
P  Fse  fn*  x  =>  e0  :  fx  f0  &  0 

f[/  h->  f,  f0]  [a;  h>  fx]  FSe  e0  :  %  k  p0 
P  hsE  fun*  /  x  =>  eo  :  tx  jea*  f0  &  0 

r  Fse  ei  :  r2  f0  &  <pi  T  Fse  e2  :t2  k  y>2 
r  t~sE  ei  e2  :  ?0  k  pi  U  p2  U  po 

£  Fse  ep  •  bool  k  po  T  Fse  e\  \t  k  p\  T  Fse  e2  :?  k  p2 
T  Fse  if  eo  then  ei  else  e2  :  f  &  po  U  pi  U  p2 

P  H~se  ei  :?i  k  p\  P[z  t->  n]  Fse  e2  :  f2  k  p2 
T  Fse  let  x  =  ei  in  e2  :  f2  k  p\  U  p2 

P  Fse  et  *  Op  &  yi  ;'T  Hse  e2  :  k  p2 

P  Fse  ei  op  e2  :  rop  k  tpi  Up2 
r  Fse  :  t  k  { !  7r}  if  r(x)  =  ref  *t 


r  Fse  e  :t  k  p 


if  T(x)  =  ref  *r 


T  Fse  x  :=  e  :t  k  pU  {n:=} 

T  Fse  et  :  fx  k  px  T[x  »->■  ref  *rj]  FSE  e2:r2  k  p2 
T  Fse  new*  x  :=  ex  in  e2  :  f2  k  (px  U  p2  U  {new7r}) 

T  Fse  e\-.Ti  k  tpi  P  Fsg  e2  :?2  k  p2 
P  FSe  ei  ;  e2  :  f2  k  px  U  p2 

r  Fse  e:r  k  p 


T  Fse  e  :t'  k  p1 


if  r  <  ?'  and  p  C  p' 


Table  5.9:  Side  Effect  Analysis. 
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In  the  clauses  [con]  and  [nor]  we  record  that  there  are  no  side  effects  so  we  use 
0  for  the  overall  effect.  The  premise  of  the  clause  [/h]  gives  the  effect  of  the 
body  of  the  function  and  we  use  that  to  annotate  the  arrow  of  the  function 
type  whereas  we  use  0  as  the  overall  effect  of  the  function  definition  itself: 
no  side  effects  can  be  observed  by  simply  defining  the  function.  A  similar 
explanation  holds  for  the  recursive  function  definition,  the  only  difference 
being  that  the  assumption  about  /  in  the  premise  has  to  use  the  same  effect 
as  the  one  determined  from  the  function  body.  In  the  rule  [app]  we  see  how 
the  information  comes  together:  the  overall  effect  is  what  we  can  observe 
from  evaluating  the  argument  ej,  what  we  can  observe  from  evaluating  the 
argument  e2,  and  what  we  get  from  evaluating  the  body  of  the  function  called. 
The  rules  [ij\,  [let]  and  [op]  should  be  straightforward. 

Turning  to  the  axioms  and  rules  involving  reference  variables  we  make  sure 
that  we  only  assign  values  of  the  appropriate  type  to  the  variable.  Also, 
in  each  of  the  cases  we  make  sure  to  record  that  a  location  at  the  relevant 
program  point  has  been  created,  referenced  or  assigned.  The  rule  [seg]  is 
straightforward  and  the  final  rule  [s«6]  will  be  explained  below. 

Example  5.26  The  following  program 


newA  x : =1 

in  (news  y:  =  !x  in  (x:  =  !y+l;  !y+3)) 

+  (newc  x:=!x  in  (x:=!x+l;  !x+l)) 

evaluates  to  8  because  both  summands  evaluate  to  4.  The  first  summand  has 
type  and  effect 

int  &  {newB,  !  A,  A:=,  !B} 
and  the  second  summand  has  type  and  effect 

int  &  {nevC,  !  A,  C:=,  !C} 

because  the  reference  variable  that  is  updated  is  the  local  one.  Hence 

int  &  {newA,  A:=,  !A,newB,  !B,newC,C:=,  !C} 

is  the  type  and  effect  of  the  overall  program.  It  follows  from  the  effect  that 
the  variable  being  created  at  B  (y  in  the  program)  is  never  reassigned  after 
its  creation.  This  might  suggest  transforming  the  news-construct  into  a  let- 
construct  (i.e.  let  y=!x  in  (x:=y+l;  y+3)).  ■ 


Subeffecting  and  subtyping.  The  purpose  of  the  rule  [su6]  in  Table 
5.9  is  to  ensure  that  we  obtain  a  conservative  extension  of  the  underlying  type 
system.  The  rule  is  really  a  combination  of  a  separate  rule  for  subeffecting 


T  I  se  e  :  f  &  <p 
T  Hse  e  :  f  &  ip' 


if  <p  C  <p' 
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and  a  separate  rule  for  subtyping : 

f  hsE  e:r  ^  ^ 

— -  if  r  <  r 

T  Fse  e:f'Szip 

Here  p  C  tp'  means  that  <p  is  “a  subset”  of  p‘  (modulo  UCAI)  as  discussed  in 
Subsection  5.2.3  (and  Exercise  5.3).  The  ordering  f  <  f '  on  annotated  types 
is  derived  from  the  ordering  on  annotations  as  follows: 

-  <  -  ft  <  Tz  <  <P  £  ?  <?'  ?'  <? 

1  ~  ’  n  ?2  <  f[  -*4  t'2  ref  t  <  ref  ?' 

Note  that  the  order  of  the  comparison  is  reversed  for  arguments  to  functions; 
we  say  that  rj  %  is  contravariant  in  Ti  but  covariant  in  <p  and  (To 
familiarise  oneself  with  this  idea  just  pretend  that  the  types  are  really  logical 
propositions  and  that  as  well  as  <  mean  logical  implication;  then  it 

should  be  clear  that  the  rule  is  the  right  one.)  Also  ref  f  is  both  covariant 
in  t  (when  the  reference  variable  is  used  for  accessing  its  value  as  in  !  r)  and 
contravariant  in  r  (when  the  reference  variable  is  used  for  assignments  as  in 
r  :=  •  •  •).  This  turns  out  to  be  essential  for  semantic  correctness  to  hold. 

This  form  of  subtyping  we  shall  call  shape  conformant  subtyping  because 
?i  <  Vi  implies  that  the  two  annotated  types  have  the  same  underlying  types, 
i.e.  [?ij  =  [?2j  and  hence  that  rj  .and  ?2  have  the  same  “shape”.  (There  are 
more  permissive  notions  of  subtypmg  than  this,  and  we  shall  return  to  it  in 
the  Concluding  Remarks.) 

Example  5.27  Consider  the  following  program 


new*  x : =1 

in  (fn  f  =>  f  (fn  y  =>  !x)  +  f  (fn  z  =>  (x:=z;  z))) 
(fn  g  =>  g  1) 


where  we  have  omitted  the  labels  on  the  function  definitions.  The  program 
evaluates  to  2  because  each  summand  evaluates  to  1. 

The  type  and  effect  of  the  two  arguments  to  f  are 

/  J  a> 

int  — - — ■¥  int  &  0 

{a:=> 

int  -  -->  int  &  0 


and  when  f  has  the  type 


•  {!a,a  :  =>  .  .  {!a,a:=} 

(int  : - 4  int)  - -4 


int 


w 
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the  application  of  f  to  the  arguments  will  be  well- typed:  we  have 

(int  — -A^>  int)  <  (int  ^'A,A~  int) 

(int  — '  int)  <  (int  ^'A’A‘  int) 

and  may  use  the  rule  for  subtyping  to  change  the  types  of  the 
the  type  expected  by  f . 

If  instead  we  had  only  used  the  rule  for  subeffecting  we  would 
let  the  two  arguments  to  f  have  type  and  effect: 


int 

{a: 

int 

& 

0 

int 

{a: 

int 

& 

0 

This  is  indeed  possible  by  using  the  rule  for  subeffecting  just  before  the  rule 
for  function  abstraction.  ■ 

The  combined  rule  [su6]  for  subeffecting  and  subtyping  gives  rise  to  a  conser¬ 
vative  extension  of  the  underlying  type  system.  This  would  also  have  been 
the  case  if  we  had  adopted  either  the  rule  for  subeffecting  or  the  rule  for 
subtyping.  However,  had  we  incorporated  no  additional  rule  then  this  would 
not  be  the  case. 

Remark.  One  can  make  a  distinction  between  “Annotated  Type  Systems” 
and  “Effect  Systems”  but  it  is  a  subtle  one  and  it  is  hardly  fruitful  to  distin¬ 
guish  them  in  a  formal  way;  yet  intuitively  there  is  a  difference.  The  analysis 
presented  in  this  subsection  is  truly  an  Effect  System  because  the  annotations 
relate  neither  to  the  input  nor  the  output  of  functions;  rather  they  relate  to 
the  internal  steps  of  the  computation.  By  contrast  the  analysis  of  Subsection 
5.1  is  an  Annotated  Type  System  because  the  annotations  relate  to  inten- 
sional  aspects  of  the  semantic  values:  what  function  abstraction  might  be  the 
result  of  evaluating  the  expression.  ■ 

5.4.2  Exception  Analysis 

Syntax.  As  our  next  analysis  we  consider  an  Exception  Analysis ;  the  aim 
of  this  analysis  is  to  determine: 

For  each  expression,  what  exceptions  might  result  from  evaluating 
the  expression. 

These  exceptions  may  be  raised  by  primitive  operators  (like  division  by  zero) 
or  they  may  be  explicitly  raised  in  the  program.  Furthermore,  there  may  be 


arguments  to 
be  obliged  to 
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the  possibility  of  trapping  an  exception  by  means  of  executing  an  expression 
designed  to  overcome  the  source  of  the  abnormal  situation.  To  illustrate  this 
scenario  we  extend  the  syntax  of  expressions  in  Fun  (Section  5.1)  as  follows: 

e  ::=  •  •  •  |  raise  s  |  handle  s  as  ex  in  ei 

The  exception  is  raised  by  the  raise-construct.  If  e 2  raises  some  exception 
si  then  handle  s-i  as  ei  in  e 2  will  trap  the  exception  in  case  si  =  S2  and 
this  means  that  ei  will  be  executed;  if  si  ^  S2  we  will  continue  propagating 
the  exception  si .  We  take  a  simple-minded  approach  to  exceptions  and  use 
strings  to  denote  their  identity. 

Example  5.28  Consider  the  following  program  computing  the  combina¬ 
torial  ^  ^  of  the  values  x  and  y  of  the  variables  x  and  y: 

let  comb  =  fun  f  x  =>  fn  y  => 

if  x<0  then  raise  x-out -of -range 
else  if  y<0  or  y>x  then  raise  y-out-of -range 
else  if  y=0  or  y=x  then  1 

else  f  (x-1)  y  +  f  (x-1)  (y-1) 
in  handle  x-out-of-range  as  0  in  comb  x  y 

The  program  raises  the  exception  x-out-of-range  if  x  is  negative  and  in 
the  body  of  the  let-construct  this  exception  is  trapped  and  the  value  0  is 
returned.  The  program  raises  the  exception  y-out-of -range  if  the  value  of 
y  is  negative  or  larger  than  the  value  of  x  and  this  exception  is  not  trapped 
in  the  program.  ■ 

Semantics.  Before  presenting  the  analysis  let  us  briefly  sketch  the  se¬ 
mantics  of  the  language.  An  expression  can  now  give  rise  to  an  exception  so 
we  shall  extend  the  set  Val  of  values  to  include  entities  of  the  form  raise 
s.  The  semantic  clauses  of  Table  5.4  then  have  to  be  extended  to  take  care 
of  the  new  kind  of  values.  For  function  application  we  shall  for  example  add 
three  rules 

b  ej  — >  raise  s 
b  ex  e2  — y  raise  s 

b  ex  — y  (fnn  x  =>  eo)  b  e2  -4  raise  s 
b  ex  e2  — y  raise  s 

b  ex  — y  (fn,r  x  =>  eo)  b  e2  -y  V2  b  eo[x  >-y  V2}  — >  raise  s 
b  ex  e2  — y  raise  s 

reflecting  that  an  exception  can  be  raised  in  any  of  the  subcomputations  in 
the  premise  of  rule  [app].  Similar  rules  are  added  for  the  other  constructs. 
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We  can  then  specify  the  meaning  of  the  new  constructs  by  the  following 
axioms  and  rules: 

1-  raise  s  — >  raise  s 

h  ^2  — >  V2  .,  , 

- - -  if  V2  9=  raise  s 

1-  handle  s  as  e\  in  e2  — >  t>2 

I-  e2  — >  raise  s  ei  — >  v\ 
h  handle  s  as  e\  in  e2  — >  V\ 

Note  that  the  expression  e2  in  handle  s  as  e\  in  e2  may  also  raise  an  ex¬ 
ception  other  than  s  in  which  case  it  will  be  propagated  out  of  the  handle- 
construct.  Similarly,  the  expression  ei  may  raise  an  exception  which  will  then 
be  propagated  out  of  the  handle-construct. 

Annotated  types.  The  purpose  of  Exception  Analysis  is  to  determine 
which  exceptions  might  be  raised  and  not  trapped  in  the  program.  We  shall 
therefore  take  the  annotations  to  be  sets  of  exceptions.  To  get  a  more  flexible 
type  system  and  a  more  powerful  analysis  we  shall  use  a  polymorphic  type 
system.  This  means  that  we  shall  allow  the  annotated  types  to  contain 
type  variables  and  also  we  shall  allow  the  annotations  to  contain  annotation 
variables.  So  the  annotations  (or  effects)  </>  £  Annes  will  be  given  by 

ip  ::=  {s}  |  U  <fi2  I  0  |  P 

and  the  annotated  types  r  €  Typegs  will  be  given  by: 

f  ::=  int  |  bool  |  ?i  -4  ?2  |  a 

As  usual  effects  will  be  considered  equal  modulo  UCAI.  To  express  the  poly¬ 
morphism  concisely  we  introduce  type  schemes.  They  have  the  form 

a  V(Ci,---,C n).r 

where  Ci> ' ‘ ’>Cn  is  a  (possible  empty)  list  of  type  variables  and  annotation 
variables;  if  the  list  is  empty  we  simply  write  f  for  VQ.r. 

Example  5.29  Consider  the  function  fnp  f  =>  f  nx  x  =>  f  x.  We  can  give 
it  the  type  schema 

V  'a,  'b,  T.  ('a  'b)  A  ('a  'b) 

which  has  instances  like 

,  {x-out-of -range}  .  .0  ..  {x-out-of-range}  .  . 

(int  - 2-4  int)  —►  (int  — - ^-4  mt) 

and  (int  -4  bool)  -4  (int  -4  bool).  ■ 


4 
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[con] 

[oar] 

\M 

[fun] 

[app] 


[let] 

[op] 

[raise] 

[handle] 

[s«6] 

[gen] 


[ins] 


f  Fes  c  :  tc  k  0 

T  (“es  x  :  a  k  0  if  r(x)  =  5 

r[z  tx]  Fes  e0  :  r0  fc  p0 
f  FEs  fn*  x  =>  eo  :  f*  ?0  &  0 

f[/  h-»  fx  r0][a;  *-»  ?x]  FEs  e0  :  f0  k  po 
f  Fes  fun*.  /  x  =>  e0  :  %  f0  &  0 


r  Fes  ei  :  r2  r0  &  <pi  T  Fes  e2  :  f2  k  p2 
r  Fes  ei  e2  :  r0  &:  <pi  U  <p2  U  p0 

£  Fes  ep  •  bool  k  pp  T  Fes  ei  :t  k  ipi  T  Fes  e2  :t  k  p2 
T  Fes  if  eo  then  e\  else  e2  :  r  k  po  U  <pi  U  <p2 

r  Fes  ei  :  ?i  fc  <pi  f[a;  t-4  ?i]  Fes  e2  :  r2  k  p2 
T  Fes  let  x  =  ei  in  e2  :  ?2  &  <pi  U  <p2 


T  Fes  ei  :  t\p  k  pi  T  Fes  e2  :  r*p  k  p2 
T  Fes  ei  op  e2  frop  &  <pi  U  <p2 

T  Fes  raise  s  :f  k  {s} 


T  FES  ei  :  f  fc  Vi  r  FEs  e2  :  f  &:  <p2 
T  Fes  handle  s  as  e\  in  e2  :  f  &  p\  U  (^2\{s}) 


T  Fes  e  :t  k  p 
r  Fes  e  :t'  k  p' 


if  f  <  t'  and  <p  C  p' 


T  Fes  e  :t  k  p 
f  Fes  e:  Vfo, •••,£„).?  &<p 
if  Ci >  •  •  •  >  Cn  do  not  occur  free  in  F  and  p 


f  Fes  e  :  V(Ci,  •  •  • .  Cn)-r  k  p 
f  Fes  e  :  (0  t)  k  p 
if  9  has  dom{9)  C  {£i ,  •  •  • ,  Cn  } 


Table  5.10:  Exception  Analysis. 
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Typing  judgements.  The  typing  judgements  for  the  Exception  Anal¬ 
ysis  will  be  of  the  form 

T  bes  e\a  h  ip 

where  the  type  environment  T  now  maps  variables  to  type  schemes.  As  ex¬ 
pected  a  denotes  the  type  schema  of  e,  and  p  is  the  set  of  exceptions  that  may 
be  raised  during  evaluation  of  e.  The  analysis  is  specified  by  the  axioms  and 
rules  of  Table  5.10.  Most  of  the  axioms  and  rules  are  straightforward  modifi¬ 
cations  of  those  we  have  seen  before;  in  the  rule  [le f]  the  use  of  a  type  schema 
for  the  let-bound  variable  is  going  to  give  us  the  required  polymorphism. 

The  axiom  [raise]  ensures  that  a  raised  exception  can  have  any  type  and 
the  effect  records  that  the  exception  s  might  be  raised.  The  rule  [handle] 
then  determines  the  effects  of  its  two  subexpressions  and  records  that  any 
exception  raised  by  e\  and  any  exception  except  s  raised  by  is  a  possible 
exception  for  the  construct.  Formally,  y>\{s}  is  defined  as  follows:  {s}\{s}  = 

0,  {s'}\W  =  {«'}  ifs'  f  s,  (¥>LV)\i>}  =  (¥>\{s})U(¥>'\M).  0\M  =  0 

and  0  \  {s}  =  0.  (We  shall  consider  alternative  definitions  shortly.) 

The  rule  [sui]  is  the  rule  for  subeffecting  and  subtyping  and  the  ordering 
r  <  f '  on  types  is  given  by 

~  ~  r[<Ti  ?2  <t!2  tpCtp' 

n  -*►  t2  <  t{  -s4  % 

as  was  also  the  case  in  Subsection  5-4.1. 

The  rules  [gen\  and  [ins]  are  responsible  for  the  polymorphism.  The  generali¬ 
sation  rule  [gen]  is  used  to  construct  type  schemes:  we  can  quantify  over  any 
type  or  annotation  variable  that  does  not  occur  free  in  the  assumptions  or  in 
the  effect  of  the  construct;  this  rule  is  usually  used  before  applications  of  the 
rule  [let].  The  instantiation  rule  [ins]  can  then  be  used  to  turn  type  schemes 
into  annotated  types:  we  just  apply  a  substitution  in  order  to  replace  the 
bound  type  and  annotation  variables  with  other  types  and  annotations  (pos¬ 
sibly  containing  type  variables  and  annotation  variables);  this  rule  is  usually 
used  after  applications  of  the  axiom  [uar]. 

Example  5.30  The  program 


let  f  =  fn  g  =>  fn  x  =>  g  x 

in  f  (fn  y  =>  if  y  <  0  then  raise  neg  else  y)  (3-2) 

+  f  (fn  z  =>  if  z  >  0  then  raise  pos  else  0-z)  (2-3) 


evaluates  to  2  because  each  of  the  summands  evaluates  to  1. 
We  may  analyse  f  so  as  to  obtain  the  type  schema 


'o 


V  'a,  'b,  '0.('a  — »  'b)  A  ('a  — »  'b) 


ii 


'o 
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and  we  may  analyse  the  two  functional  arguments  to  f  so  as  to  obtain: 

int  -{— g}>  int  k  0 
int  {Pos^>  int  k  0 


We  can  now  take  two  instances  of  the  type  schema  for  f :  to  match  the  first 
argument  of  f  we  use  the  substitution  ['a  i-»  int;  'b  t-t  int;'0  {neg}]  and  to 
match  the  second  argument  we  use  ['a  i->  int;'b  int;'0  i-4  {pos}].  Hence 
the  type  and  effect  of  each  summand  is 

int  Sz  {neg} 
int  k  {pos} 


and  therefore 


int  &  {neg, pos} 

is  the  overall  type  and  effect  of  the  entire  program. 

If  we  did  not  avail  ourselves  of  polymorphism  we  would  have  to  rely  on 
subeffecting  and  subtyping  and  let  f  have  the  type 

(int  ■g-eg'P^  int)  A  (int  -fiSKS,  int) 


which  is  more  imprecise  than  the  type  scheme  displayed  above,  although  we 
would  still  be  able  to  obtain  int  k  {neg,  pos}  as  the  overall  type  and  effect 
of  the  entire  program.  -  ■ 

Remark.  The  judgements  of  the  Exception  Analyses  were  of  the  form 
f  Fes  e  :  a  k  ip  but  nonetheless  most  axioms  and  rules  of  Table  5.10  have 
had  conclusions  of  the  form  f  Fes  e  :  t  k  ip.  By  changing  rules  [if],  [let], 
[raise],  [ handle ]  and  possibly  [s«6]  one  can  obtain  a  more  liberal  system  for 
Exception  Analysis.  We  leave  the  details  for  Exercise  5.14. 

In  the  rule  [handle]  we  make  use  of  the  notation  ip  \  {s}  and  we  next  defined 
/?\{s}  =  P  even  though  P  might  later  be  instantiated  to  {s}.  Since  /3\{s}  C  /? 
should  hold  for  all  instantiations  of  P,  this  is  semantically  sound  (correspond¬ 
ing  to  what  happens  in  the  rule  [sub]).  To  define  a  less  approximate  system 
it  would  be  natural  to  let 


ip  ::=■■■  |  <p\{s} 

and  then  to  extend  the  axiomatisation  of  UCAI  to  deal  with  set  difference.  ■ 

5.4.3  Region  Inference 

Let  us  once  again  consider  the  language  Fun  as  introduced  in  Section  5.1. 
The  purpose  of  Region  Inference  is  to  facilitate  implementing  Fun  in  a  stack- 
based  as  opposed  to  a  heap-based  regime  as  is  usually  the  case;  since  the 
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(rl.oi) 


(rl,l) 


(r2,02) 

(r2,l) 


(r3  ,o3) 

(r3,l) 


rl  r2  r3 


Figure  5.1:  The  memory  model  for  the  stack-based  implementation  of  Fun. 


stack-based  regime  is  quite  efficient  in  reusing  dead  memory  locations  without 
relying  on  explicit  garbage  collection  this  might  lead  to  an  efficient  implemen¬ 
tation.  But  functions  axe  statically  scoped  and  can  produce  other  functions 
as  results,  so  it  is  by  no  means  clear  that  a  stack-based  regime  should  be 
possible;  the  purpose  of  region  inference  is  to  analyse  how  far  locally  allo¬ 
cated  data  can  be  passed  around  so  that  the  allocation  of  memory  can  be 
performed  in  an  appropriate  manner.  This  leads  to  a  memory  model  for  the 
stack-based  regime  where  the  memory  is  a  stack  of  dynamic  regions  (rl,  r2, 
r3,  •  •  •)  and  each  dynamic  region-  is  an  indexed  list  (or  array)  of  values  as 
illustrated  in  Figure  5.1. 

Syntax.  To  make  this  feasible  we  shall  introduce  a  notion  of  extended 
expressions  that  contain  explicit  information  about  regions.  To  this  end  we 
introduce  region  names,  region  variables,  and  static  regions 

rn  G  RName  region  names 
q  G  RVar  region  variables 
r  G  RegR|  regions 

as  follows: 

rn  rl  |  r2  |  r3  |  •  •  • 

e  ::=  "l  |  "2  |  "3  |  •  •  • 
r  ::=  g  |  rn 

The  syntax  of  extended  expressions 

ee  G  EExp 


is  given  by: 

ee  ::=  c  at  r  \  x  j  fn*  x  =>  eeo  at  r  |  fun,,  f  [q\  x  ->  eeo  at  r  |  eei  ee2 
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|  if  eeo  then  eei  else  ee2  |  let  x  =  ee\  in  ee2  |  eei  op  ee2  at  r 
|  ee[r\  at  r  |  letregion  g  in  ee 

Here  we  write  g  for  a  possibly  empty  sequence  g\ ,  •  •  • ,  gk  of  region  variables 
and  similarly  r  for  a  possible  empty  sequence  ri ,  •  •  • ,  r*  of  regions.  The 
main  point  of  the  extended  expressions  is  that  if  a  subexpression  explicitly 
produces  a  new  value  then  it  has  an  explicit  placement  component,  “at  r”, 
that  indicates  the  region  in  which  the  value  is  (to  be)  placed.  The  letregion- 
construct  explicitly  allows  to  deallocate  the  regions,  g,  that  are  no  longer 
needed  and  the  placement  construct,  ee[r\  at  r,  allows  us  to  explicitly  place 
a  “copy”  of  ee  (typically  a  recursive  function)  in  the  region  r.  The  construct 
for  recursive  function  definitions  explicitly  takes  a  sequence  of  region  variables 
as  parameters;  intuitively,  this  ensures  that  the  various  incarnations  of  the 
recursive  function  can  have  its  local  data  in  different  regions. 

Example  5.31  The  relationship  between  expressions  and  extended  ex¬ 
pressions  will  be  clarified  when  presenting  the  typing  judgements  below.  For 
now  we  merely  state  that  the  expression  e 

(let  x  =  7  in  fny  y  =>  y+x)  9 

will  give  rise  to  the  extended  expression  ee: 

letregion  gr ,  g3,  g\ 
in  (let  x  =  (7  at  g{) 

in  (fnY  y  =>  (y+x)  at  g2)  at  g3)  (9  at  g4) 

Here  the  value  7  is  placed  in  the  region  glt  the  value  of  x+y  in  region  g2, 
the  function  named  Y  in  the  region  £3  and  the  argument  9  in  region  £>4. 
The  final  value  (which  is  7  +  9  =  16)  is  therefore  to  be  found  in  region  g2. 
All  other  regions  (g  1,  g3,  and  £>4)  no  longer  serve  any  purpose  and  can  be 
deallocated;  this  is  made  explicit  by  the  letregion-construct.  In  the  version 
of  the  program  that  is  actually  run  we  should  replace  the  metavariables  g  1, 
g3  and  g4  by  region  variables  "1,  "2,  and  "3  and  furthermore  the  free  region 
variable  g2  should  be  replaced  by  a  region  name  such  as  rl.  ■ 

Semantics.  The  Natural  Semantics  of  expressions  is  given  by  Table  5.4 
and  we  now  devise  a  Natural  Semantics  for  the  extended  expressions  so  as  to 
make  the  role  of  regions  clear.  The  transitions  takes  the  form 

p\-  (ee,  t)  — >  (v,0 

where  p  is  an  environment,  ee  is  an  extended  expression,  c  and  c'  are  stores 
(as  in  Figure  5.1)  and  v  is  an  expressible  value.  Formally  we  shall  use  the 
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domains: 

p  €  Env  =  Var*  -)■  EVal 

v  G  EVal  =  RName  x  Offset 

o  G  Offset  =  N 

C  €  Store  =  RName  -»fin  (Offset  -»fin  SVal) 

w  €  SVal 

Here  Var*  is  the  finite  set  of  variables  in  the  extended  expression  ee*  of 
interest,  a  store  is  a  stack  of  regions  (where  the  stack  is  modelled  as  a  fimtary 
mapping  from  region  names),  a  region  is  a  list  of  storable  values  (where  the 
list  is  modelled  as  a  finitary  mapping  from  indices  called  offsets),  and  a 
storable  value  is  given  by 

w::=c  |  {x,ee,p)  |  (e,x,ee,p) 

consisting  of  ordinary  constants,  closures,  and  so-called  region  polymorphic 
closures.  In  addition  to  the  formal  parameter,  the  body  of  the  function, 
and  the  environment  at  the  definition  point,  a  region  polymorphic  closure 
also  contains  a  list  of  formal  region  parameters  that  have  to  be  instantiated 
whenever  the  function  is  called  -  in  this  way  it  is  explicityly  ensured  that 
the  local  data  can  be  properly  placed  in  the  store  for  each  function  call. 
To  simplify  the  notation  we  shall  allow  to  view  a  store  as  an  element  of 
RName  x  Offset  ->fi„  SVal  and  go  write  c(r,  o)  for  ?(r)(o)  etc.  All  ordinary 
values  are  “boxed”  which  means  that  they  are  always  placed  in  the  store  and 
hence  an  expressible  value  is  always  a  pair  consisting  of  a  region  name  and 
an  offset. 

The  semantics  is  defined  in  Table  5.11  and  is  explained  below.  We  intend 
that  an  extended  expression  does  not  contain  free  region  variables  when  eval¬ 
uated  and  hence  many  r’s  have  become  rn’s.  The  axiom  [con]  for  constants 
explicitly  allocates  a  new  offset  in  the  relevant  region  and  places  the  constant 
in  that  cell.  The  axiom  [var]  for  variables  does  not  involve  the  allocation  of 
a  new  offset  and  merely  performs  a  lookup  in  the  environment. 

The  axiom  [fn]  for  function  abstraction  allocates  a  new  offset  where  it  stores 
an  ordinary  closure  consisting  of  the  formal  parameter,  the  body  of  the  func¬ 
tion,  and  the  current  environment.  The  axiom  [fan]  for  recursive  functions 
constructs  a  region  polymorphic  closure  that  records  the  list  of  formal  region 
variables  to  be  instantiated  by  means  of  the  placement  construct  explained 
below;  also  note  that  recursion  is  handled  by  updating  the  current  environ¬ 
ment  with  a  reference  to  the  function  itself. 

The  rules  [app],  [ i/x ] ,  [if2]  and  [let]  should  be  straightforward  and  the  rule  [op] 
for  binary  operations  allocates  a  new  offset  for  the  result. 

The  rule  [place]  takes  care  of  the  situation  where  an  extended  expression 
(such  as  a  variable  or  a  recursive  function  definition)  evaluates  to  a  region 
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[con] 

[mrj 

IM 

[fun] 

[app] 

[*/i] 

[</2] 

[let] 

[op] 

[place ] 

[region] 


p  h  (c  at  rn,g)  — >  ((rn,o),c[(rn,o)  i-4  c]) 
if  o  &  dom(<;(rn)) 

p\-  (x,q)  — >  ( p(x),g ) 

p  h  ((fn*  x  =>  eeo)  at  rn,?)  — > 

((rn,o),?[(rn,o)  i-4  (s,ee0,p)]) 

if  o  #  dom(<;(rn)) 

p  F  ((fun*  /[p]  x  =>  ee0)  at  rn,?)  — >■ 

{( rn,o),?[(rn,o )  (g,x,ee0,p[f  (rn,o)])]) 

if  o  £  dom(q(rn)) 

p\-  (eei,?i)  — ►  ((rm,oi),?2)  pY-  (ee2,?2)  — >  («2,C3> 

_ Po[x  >-»  v2]  Y-  (ee0,?3)  — >  (uq,?4) _ 

pY-  (eei  ee2,?i)  — *  (uo,Ci) 
if  ft(rni,oi)  =  (x,ee0,p0) 

pF(ee0,?  1) — >■  ((rn,o),?2)  p  F  (eei , <?2) — t  (ui,?3) 
p  F  (if  ee0  then  eei  else  ee2,?i)  — ►  (vuS3) 
if  ?2(rn,o)  =  true 

p\~  {ee 0,ft) — >  {(rn\o),g2)  pF(ee2,? 2) — >  («2,C3) 
p  h  (if  ee0  then  eei  else  ee2,ci)  — >  (f 2 , C3 ) 
if  ?2  (rn,  o)  =  false 

P  F  (eei, ft)  — >■  (^1^2)  pfr  ^  ^1)  F  (ee2,ft)  — >■  (u2,?3) 
p  F  (let  x  =  eei  in  ee2,?i)  — >  (u2,?3) 

P  F  (eei, ft)  — >  ((rni,oi),ft)  pF  (ee2,ft)  — >■  ((rn2,o2),?3) 
p  F  ((eei  op  ee2)  at  rn,?i)  — »  ((rn,o),?3[(rn,o)  u]) 

if  ft(rni,pi)  op  ft(rn2,o2)  =  v  and  o  &  dom{q3(rn)) 

_ pF  (ee,ft)  — >  ((rn',o'),ft) _ 

pF  (ee[rn]  at  rn,?i) 

— >  ((rn,o),?2[(rn,o)  k*  (x,ee0[p  rn],p0)]) 
if  o  £  dom(g2(rn))  and  ft(rn',o')  =  ( g,x,ee0,po ) 

p  F  (ee[g  rn],ft[rn  1— >■  [  ])  — »■  (u,?2) 
p  F  (letregion  g  in  ee,ft)  — >  (u,?2 \rn) 
if  {rn}  (1  dom(?)  =  0 


Table  5.11:  Natural  Semantics  for  extended  expressions. 


5.4  Effects 


329 


polymorphic  closure.  The  placement  construct  ee[r\  at  r  then  allocates  a 
new  cell  in  the  region  r  and  stores  a  copy  of  the  region  polymorphic  closure 
in  the  cell  except  that  it  ensures  that  the  list  of  formal  region  parameters  is 
replaced  by  a  list  of  the  actual  region  names;  this  is  an  important  feature  for 
allowing  each  recursive  call  of  a  function  to  allocate  its  auxiliary  data  locally 
on  the  stack  rather  than  being  lumped  together  (in  the  heap)  with  data  from 
other  recursive  calls. 

Finally,  the  rule  [ region ]  for  the  letregion-construct  allocates  new  unused 
region  names  to  be  used  instead  of  the  region  variables,  evaluates  the  enclosed 
extended  expression,  and  finally  deallocates  the  newly  allocated  region  names; 
formally,  dom(<;\rn)  =  dom(q)  \  {rn}  and  V(rn,  o)  €  dom(q\rn)  :  c(rn,  o)  = 
(q\rn)(rn,o). 

Annotated  types.  When  analysing  the  extended  expressions  we  shall 
want  to  keep  track  of  those  regions  that  may  be  affected  during  evaluation: 
in  what  regions  do  we  place  (or  put)  data  and  from  what  regions  do  we 
access  (or  get)  date.  This  is  somewhat  analogous  to  the  Side  Effect  Analysis 
of  Subsection  5.4.1  and  will  be  taken  care  of  using  the  effects  to  be  defined 
below.  Another  purpose  of  the  analysis  is  to  keep  track  of  the  regions  in 
which  the  values  reside.  To  this  end  we  shall  say  that  an  extended  type  is  a 
pair 

r@r 

consisting  of  an  annotated  type  and  the  region  where  the  value  resides.  For¬ 
mally,  annotations  (or  effects),  annotated  types  and  type  schemes 

ip  €  Annpi  effects 
f  €  TypeR,  annotated  types 
ct  €  Schemepi  type  schemes 

are  given  by: 

tp  "=  (put  r}  |  {get  r)  |  <pi  U  v?2  |  0  |  P 

t  ::=  int  |  bool  |  (?i@ri)  (r2@r2)  |  a 

G  ::=  V(Q!i,  *  *  •  ,  Q!n),  (ft  ,  *  * ' ,  ftn) ,  ,  •  •  '  ,  .T 

|  V(ai,  •••,£*„),  (ft,  •••,/?„,).? 

Here  we  distinguish  between  two  kinds  of  type  schemes:  compound  type 
schemes  (with  [g])  to  be  used  for  recursive  functions  and  ordinary  type 
schemes  (without  [<?]).  We  shall  write  f  for  V(),().r  whereas  we  only  al¬ 
low  to  write  V[  ].?  for  V(),  (),  [  ].r;  in  this  way  the  two  kinds  of  type  schemes 
can  always  be  distinguished.  The  use  of  an  annotation  variable,  (3,  in  the 
annotation  placed  on  the  function  arrow,  ftyj,  is  related  to  the  use  of  sim¬ 
ple  types  in  Section  5.3  and  is  mainly  of  interest  for  the  inference  algorithm; 


i. 

i 
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for  the  present  purposes  /?.<p  can  be  read  as  f3  U  p  although  the  inference 
algorithm  will  view  it  as  the  constraint  (3  D  /3  U  <p. 

Example  5.32  Returning  to  the  extended  expression  ee 

letregion  git  g3,  g4 
in  (let  x  =  (7  at  £>i) 

in  (fnY  y  =>  (y+x)  at  g2)  at  g3)  (9  at  g4) 

of  Example  5.31,  the  subexpression  7  at  gi  will  have  the  annotated  type 
int@£>i,  the  function  abstraction  (fny  y  =>  (y+x)  at  g2)  at  £>3  will  have  the 
annotated  type 

((int@£>4)  (int@£2))@£>3 

where  p  =  {get  04, get  01, put  g2},  and  the  overall  expression  will  have  the 
extended  type  int@^2-  ■ 

Typing  judgements.  It  would  be  quite  feasible  to  define  typing  judge¬ 
ments  for  verifying  that  extended  expressions  are  correctly  typed.  However, 
the  main  use  of  region  inference  is  to  facilitate  the  implementation  of  Fun 
and  for  this  reason  we  shall  touch  upon  Section  1.8  and  let  the  typing  judge¬ 
ments  also  describe  how  to  translate  expressions  into  extended  expressions. 
This  suggests  using  typing  judgements  of  the  form 

r  I-R|  e  ee  :  r@r  &  p 

where  T  is  a  type  environment  mapping  variables  into  extended  type  schemes 
that  are  pairs  consisting  of  a  type  scheme  and  a  region. 

The  analysis  is  defined  in  Tables  5.12  and  5.13  and  is  explained  below.  The 
axiom  [con]  for  constants  inserts  an  explicit  placement  component  and  records 
the  placement  in  the  effect.  The  axiom  [oar]  for  variables  is  straightforward 
as  it  involves  no  explicit  placements. 

The  rule  [fn]  for  ordinary  function  abstraction  transforms  the  body  of  the 
function  and  then  inserts  an  explicit  placement  component  for  the  function 
itself.  The  rule  [fun ]  for  recursive  functions  involves  a  restricted  form  of  poly¬ 
morphic  recursion  (excluding  type  variables  as  this  would  be  undecidable): 
polymorphic  recursion  means  that  when  analysing  the  body  of  the  function 
we  are  allowed  to  use  the  recursive  function  polymorphically.  This  generality 
gives  much  more  precise  type  information  and  is  essential  for  the  success  of 
region  inference.  For  conciseness  the  rule  has  been  presented  in  a  non  syntax 
directed  manner  where  the  rule  for  ordinary  functions  is  needed  to  analyse 
the  premise;  clearly  the  rule  could  have  been  expanded  so  as  to  be  syntax  di¬ 
rected.  The  rules  for  application,  conditional,  local  definitions  and  operators 
are  straightforward. 
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[con]  rhR|CMcatr:  (rc@r)  &  {put  r} 
[war]  T  Hri  x  x  :  a  &  0  if  f(i)  =  a 


\M 


[fun] 


£[x  i-»  Hri  e0  -v->  ee0  :  (f0@r0)  fe  tp0 

T  I  ri  fn*  x  =>  eo  (fn*  x  =>  eeo)  at  r  : 

(( ?x@rx  fo@r0)@r)  &  {put  r} 

f  [/  (V/3,  [p].r)@r]  I-ri  fn*  x  =>  e0 

(fn*  x  =>  eeo)  at  r  :  (f@r)  &  <p 

T  f-Ri  fun*  /  x  =>  e o  (fun*  /  [p]  x  =>  eeo)  at  r  : 

((V/3,  [p].r)@r)  &  <p 

if  /?  and  q  do  not  occur  free  in  T  and  <p 


[app\ 


W! 


[let] 


r  I  ri  ei  eei  :  ((T2@r2  ?o@ro)@ri)  &  <pi 

T  f-Ri  e2  ee2  :  (r2@r2)  &  <p2 


f  Hri  ex  e2 

eei  ee2  :  (fo@ro) 

&<Pi  U  <p2  U  po  U  /3o  U 

{get  ri} 

r  I-ri  eo  eeo  : 

(bool@r0)  &  ipo 

r  I-ri  ei 

eei  :  (r@r)  &  <pi 

T  Hri  e2  ee2  :  (f@r)  &  p2 

T  1  ri  if  e0  then  ei  else  e2 

■  if  eeo  then  eei  else 

ee2  : 

(? 

•@r)  &  <p0  U  tpi  U  <P2  U 

{get  r0} 

f  hR|  ei  eei 

:  (?i@ri)  &  <pi 

T[x  5i@ri]  hR|  e2 

ee2  :  (r2@r2)  &  <p2 

T  h- ri  let  x  =  ei  in  e2  let  x  =  eei  in  ee2  :  (r2@r2)  &  g>\  U  <p2 


f  hR|  ei  eei  :  (r*p@ri)  &  ipx 

_ f  I-ri  e2  ee2  :  (r^p@r2)  &:  y?2 _ 

T  (-ri  ei  op  e2  (eei  op  ee2)  at  r  : 

(rop@r  &  <pi  U  <p2  U  {get  ri ,  get  r2,  put  r} 


Table  5.12:  Region  Inference  Analysis  and  Translation  (part  1). 


Then  we  have  a  rule  [su6]  for  subeffecting  and  subtyping ;  clearly  one  could  de¬ 
cide  to  dispense  with  subtyping  in  which  case  subeffecting  could  be  integrated 
with  function  abstraction  as  illustrated  in  Section  5.1. 

There  are  two  rules  [gen\]  and  [</en2]  for  generalising  over  type  variables.  One 
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[su6] 


[</eni] 


T  Fri  e  ee  :  (f@r)  &  ip 
T  hRi  e  ee  :  (r'@r)  &  y?' 


if  t  <  t'  and  ip  C  ip' 


T  Fri  e  ee  :  (f  @r)  &  <^> 
r  Fri  e  ee  :  ((Va.r)@r)  & 
if  a  do  not  occur  free  in  T  and  ip 


[gen2] 


T  Fri  e  ee  :  ((V/3,  [p].T)@r)  & 
r  Fr,  e  ee  :  ((Va,  /3,  [^].f)@r)  &  <p 
if  5  do  not  occur  free  in  T  and  <p 


[insi] 


r  Fri  e  ee  :  ((Va,  $.t )@r  &c  ip 

T  Fri  e  ee  :  ((9  f )@r)  &  <p 
if  #  has  dom{9)  C  {a,  /?} 


[ins2] 


f  Fri  e  ee  :  ((Va,  (3,  [$].T)@r)  & 
r  Fri  e  ee[6g[  at  r' :  (( 6  ?)@r')  &  U  {get  r,  put  r1} 
if  9  has  dom(9)  C  {a,  p} 


.  ,  T  Fri  e  ee  :  (f@r)  &  ip 

[region]  — - 7 - 

T  Fr,  e  ^  letregion  g  in  ee  :  (r @r)  &  <p' 

if  <p'  =  Observe(r,r,r)(tp )  and  g  occurs  in  ip  but  not  in  ip' 


Table  5.13:  Region  Inference  Analysis  and  Translation  (part  2). 


applies  to  ordinary  types  and  the  other  to  compound  type  schemes.  In  both 
cases  we  could  have  adapted  the  rule  so  as  also  to  generalise  over  (additional) 
region  and  effect  variables;  however,  even  when  doing  so,  the  type  inference 
is  quite  separate  from  the  region  and  effect  inference. 

There  are  two  inference  rules  [insi]  and  [11152]  for  instantiating  a  type  scheme. 
One  is  for  ordinary  types  schemes  and  is  invisible  as  far  as  the  syntax  of  the 
extended  expression  is  concerned.  The  other  is  for  compound  type  schemes 
and  is  visible  in  the  extended  expression  in  that  an  explicit  placement  con¬ 
struct  is  introduced;  additionally  the  effect  records  that  the  value  has  been 
accessed  and  placed  again.  Both  rules  would  typically  be  used  immediately 
after  the  axiom  for  variables. 

The  rule  [region]  for  the  letregion-construct  uses  an  auxiliary  function, 
Observe  ,  to  reduce  the  effect  to  what  is  visible  from  the  outside;  region  vari¬ 
ables  that  are  no  longer  visible  can  then  be  encapsulated  within  the  program. 
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The  auxiliary  function  may  be 
Observe(r, f, r')({put  r})  = 

Observe(r,f,r/)({get  r})  = 

Observe(T, f, r')(y> i  U  <^2)  = 

Observe(r,f,r')(0)  = 


defined  as  follows: 

{{put  r}  if  r  occurs  in  T,  f ,  or  r' 

0  otherwise 

f  {get  r}  if  r  occurs  in  T,  r,  or  r' 

\  0  otherwise 

Observe(T,T,r')(ipi)  U  Observer, r,r')(y>2) 

0 


Observe(F,  r,  r')(/3) 


{yd  if  /3  occurs  in  T,  f ,  or  r' 
%  otherwise 


Example  5.33  In  Example  5.31  we  considered  the  expression  e 

(let  x  =  7  in  fny  y  =>  y+x)  9 

and  the  extended  expression  ee: 

letregion  glt  g3,  q4 
in  (let  x  =  (7  at  gi) 

in  (fnY  y  =>  (y+x)  at  g2)  at  03)  (9  at  g4) 

One  can  now  show  that  [  ]  hR|  e  ee  :  (int@f>2)  &  {put  f>2}.  ■ 


5.5  Behaviours 

So  far  the  effects  have  had  a  rather  simple  structure  in  that  they  merely 
denote  sets  of  atomic  actions  like  accessing  a  value  or  raising  an  exception. 
The  effects  have  not  attempted  to  capture  the  temporal  order  of  these  atomic 
actions.  Often  such  information  would  be  useful  for  example  to  check  that 
a  variable  is  not  accessed  until  after  it  has  been  assigned  a  value.  In  this 
section  we  shall  show  how  to  devise  a  Type  and  Effect  System  where  effects 
(called  behaviours)  are  able  to  record  such  temporal  ordering  in  the  context 
of  a  Communication  Analysis  for  a  fragment  of  Concurrent  ML. 

5.5.1  Communication  Analysis 

Syntax.  Let  us  consider  an  extension  of  the  language  Fun  with  con¬ 
structs  for  generating  new  processes,  for  communicating  between  processes 
over  typed  channels,  and  for  creating  new  channels.  The  syntactic  category 
e  €  Exp  of  expressions  is  now  given  by: 

e  ::=  •  •  •  |  channel*-  |  spawn  eo  |  send  e\  on  e2  |  receive  eo  |  ei;e2  |  ch 
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Figure  5.2:  The  pipeline  produced  by  pipe  [f  i ,  f 2]  inp  out. 


Here  channel*-  creates  a  new  channel  identifier  (denoted  ch  above),  spawn  eo 
generates  a  new  parallel  process  that  executes  eo,  and  send  v  on  ch  sends  the 
value  v  to  another  process  ready  to  receive  a  value  by  means  of  receive  ch; 
sequential  composition  is  as  before.  Channel  identifiers 

ch  €  Chan  channel  identifiers 

are  created  dynamically  and  are  given  by: 

ch  ::=  chanl  |  chan2  j  •  •  • 

Also  we  shall  assume  that  the  constants,  c  €  Const,  not  only  include  integers 
and  booleans  but  also  a  special  value  called  unit  and  denoted  by  0;  this  is 
the  value  to  be  returned  by  the  spawn  and  send  constructs. 

Example  5.34  In  this  example  we  shall  imagine  that  the  expressions  are 
extended  with  operations  on  lists:  isnii  e  tests  whether  or  not  the  list  e 
is  empty,  hd  e  selects  the  first  element  and  tl  e  selects  the  remainder  of 
the  list.  We  now  define  a  function  pipe  that  takes  a  list  of  functions,  an 
input  channel  and  an  output  channel  as  arguments;  it  constructs  a  pipeline 
of  processes  that  apply  the  functions  to  the  data  arriving  at  the  input  channel 
and  returns  the  results  on  the  output  channel  (see  Figure  5.2).  It  makes  use 
of  the  function  node  that  takes  a  function,  an  input  channel  and  an  output 
channel  as  arguments  and  it  is  defined  as  follows: 

let  node  =  fnF  f  =>  fni  inp  =>  fno  out  => 

spawn  ((funn  h  d  =>  let  v  =  receive  inp 

in  send  (f  v)  on  out; 
h  d)  ()) 

in  funp  pipe  fs  =>  fm  inp  =>  fno  out  => 

if  isnii  fs  then  node  (fnx  x  =>x)  inp  out 
else  let  ch  =  channelc 

in  (node  (hd  fs)  inp  ch;  pipe  (tl  fs)  ch  out) 

To  deal  with  the  empty  list  the  function  produces  a  process  that  just  applies 
the  identity  function  (denoted  id  in  Figure  5.2).  ■ 
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(fn*  x  =>  e)  v  -»  e[x  u] 
let  x  =  v  in  e  ->  e[x  i->  u] 

^1  Op  V2  -¥  v  if  ui  op  «2  =  u 

fun*  /  x  =>  e  -¥  (fnff  x  =>  e)[/  t->  (funK  f  x  =>  e)] 

if  true  then  ei  else  e2  ->  ei 

if  false  then  e\  else  e2  -¥  e2 

v,  e  ->  e 

Table  5.14:  The  sequential  semantics. 


Semantics.  We  shall  begin  by  defining  the  operational  semantics  of  the 
sequential  fragment  of  the  language  and  then  show  how  to  incorporate  it  into 
the  concurrent  fragment.  This  will  make  use  of  a  notion  of  evaluation  context 
in  order  to  obtain  a  succinct  specification  of  the  semantics.  The  sequential 
fragment  is  evaluated  in  an  eager  left  to  right  manner  and  does  not  need  any 
notion  of  a  store,  a  state  or  an  environment.  A  fully  evaluated  expression 
gives  rise  to  a  value  which  is  a  constant,  a  channel  identifier  or  a  function 
abstraction.  This  may  be  modelled  by 

v  6  Val  values 


defined  by: 


v  c  |  ch  \  fnn  x  =>  eo 


There  is  no  need  to  package  the  function  abstraction  with  an  environment 
because  the  semantics  will  treat  a  function  application  (fn*  x  =>  e0)  v  by 
substituting  v  for  x  in  eo  yielding  eo[x  v]. 

Part  of  the  sequential  semantics  is  specified  in  Table  5.14.  In  the  manner  of 
a  Structural  Operational  Semantics  it  axiomatises  the  relation 


ei  e2 


for  when  the  expression  ei  in  one  step  evaluates  to  e2-  However,  it  does  not 
describe  how  e\  may  evaluate  to  e2  as  a  result  of  a  subcomponent  eu  of  e\ 
evaluating  to  ei2  unlike  what  has  been  the  case  for  the  Structural  Operational 
Semantics  used  so  far.  As  an  example  Table  5.14  cannot  be  used  to  show 
that  (l  +  2)+4-+3  +  4  although  it  can  be  used  to  show  that  1  +  2  ->  3. 

To  recover  from  this  shortcoming  we  shall  make  use  of  evaluation  contexts] 
these  are  expressions  containing  one  hole  which  is  written  [  ].  Formally, 
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evaluation  contexts  E  are  given  by: 

E  ::=  [  ]  |  E  e  |  v  E  |  let  x  =  E  in  e 

|  if  E  then  e\  else  e2  |  E  op  e  |  v  op  E 

|  send  E  on  e  |  send  v  on  E  |  receive  E  |  E;e 


Here  the  syntax  ensures  that  £  is  an  expression  containing  exactly  one  hole 
while  e  is  an  ordinary  expression  without  any  holes.  The  definition  of  E  may 
be  read  as  follows:  you  are  allowed  to  evaluate  an  expression  on  its  own, 
you  may  evaluate  the  function  part  of  an  application,  you  may  evaluate  the 
argument  part  of  an  application  only  after  the  function  part  has  been  fully 
evaluated  etc.  We  shall  write  E[e]  for  the  expression  obtained  by  replacing 
the  hole  of  E  with  e  so  for  example  if  E  is  [  ]  +  4  then  E[e]  is  e  +  4.  We 
dispense  with  the  detailed  definition  of  E[e ]  because  it  is  straightforward: 
since  the  hole  in  E  never  occurs  in  the  scope  of  a  bound  variable  there  is  no 
risk  of  variable  capture. 

The  basic  idea  then  is  to  stipulate  that  e\  evaluates  to  e2  in  one  step  (ei  =+  e2) 
if  there  exists  E,  eio  and  e2o  such  that  e\  =  E[e io],  eio  -+  e2o  and  e2  =  £[e2 o]. 
As  an  example,  (l+2)+4  =>  3+4  by  taking  E  to  be  []+4,  eio  to  be  1  +  2  and 
e2o  to  be  3.  Note  that  having  E  op  e  as  an  evaluation  context  corresponds 
to  having  an  inference  rule 

_ eio  ~+  620 _ 

eio  op  e2  — >  e2o  op  e2 

as  in  Table  3.3.  As  already  said,  an  advantage  of  using  evaluation  contexts  is 
that  the  description  of  the  semantics  often  becomes  more  succinct;  we  shall 
benefit  from  this  below. 


The  concurrent  semantics  operates  on  a  finite  pool,  PP,  of  processes  and  a 
finite  set,  CP,  of  channels.  The  set  of  channels  keeps  track  of  those  chan¬ 
nels  that  have  been  generated  so  far;  this  allows  us  to  evaluate  channel^ 
by  generating  a  new  channel  that  has  never  been  used  before.  The  pool  of 
processes  both  keeps  track  of  the  processes  spawned  so  far  and  of  the  expres¬ 
sion  residing  on  each  process;  this  allows  us  to  allocate  new  processes  when 
an  expression  is  spawned  and  to  let  distinct  processes  communicate  with  one 
another.  Formally 

p  €  Proc  processes 


is  defined  by 
and  we  take 


p  ::=  procl  |  proc2  |  •  •  • 

CP  e  Pfin(Chan) 

PP  €  Proc  -»fin  Exp 


where  it  will  be  the  case  that  each  PP(p )  is  a  closed  expression.  We  shall 
write  PP\p  :  e]  for  PP'  given  by  dom(PP')  =  dom(PP)  U  {p},  PP' {p)  =  e 
and  PP'(q)  =  PP{q)  for  q  ^  p. 
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[seq]  CP,  PP\p  :  J5[ex]]  =»  C7P,  PP\p  :  P[e2]] 
if  ej  ->  e2 

[chan]  CP,  PP[p  :  Pfchannel*]]  =>■  CP  U  {ch},  PP[p  :  F[ch]] 
if  ch  g  CP 

[spawn]  CP,  PP{p  :  P[spawn  e0)]  CP,  PP[p  :  £[()]][p0  :  e0] 
if  po  dom(PP)  U  {p} 

[comm]  CP,  PP[pi  :  Pi  [send  v  on  c/i]] [j>2  :  P2[receive  ch]] 

=►  CP,PP\pi  :  ^i[0]][P2  :E2[v]] 
if  Pi  ±  P2 


Table  5.15:  The  concurrent  semantics. 


The  concurrent  semantics  is  specified  in  Table  5.15.  It  is  a  Structural  Oper¬ 
ational  Semantics  that  axiomatises  the  relation  CPi.PPi  =$>  CP2,PP2  for 
when  one  configuration  CP i ,  PPi  in  one  step  evolves  into  another  configu¬ 
ration  CP2,PP2.  Thanks  to  the  use  of  evaluation  contexts  all  clauses  can 
be  written  succinctly.  The  clause  [seg]  incorporates  the  sequential  semantics 
into  the  concurrent  semantics  (and  corresponds  to  the  discussion  of  ei  =>•  e2 
above).  The  clause  [c/ian]  takes  care  of  the  allocation  of  channels:  channel^ 
is  replaced  by  a  fresh  channel  identifier  ch.  The  clause  [spawn]  generates  a 
new  process,  initialises  it  to  the  expression  to  be  executed,  and  replaces  the 
spawn-construct  by  the  unit  value.  Finally,  the  clause  [comm]  allows  syn¬ 
chronous  communication  between  distinct  processes:  the  receive-construct 
is  replaced  by  the  value  being  sent  and  the  send-construct  is  replaced  by  the 
unit  value. 

Annotated  types.  The  purpose  of  the  Communication  Analysis  is  for 
each  expression  to  determine  its  communication  behaviour:  what  channels 
will  be  allocated,  what  type  of  entities  will  be  sent  and  received  over  channels, 
and  what  is  the  behaviour  of  the  processes  being  generated:  furthermore, 
we  are  interested  in  recording  the  temporal  order  (or  “causality”)  among 
these  actions:  what  takes  place  before  what.  There  are  several  ways  to 
formalise  this  and  we  shall  choose  one  where  the  inference  system  is  not  overly 
complicated  (but  where  the  inference  algorithm  presents  some  challenges). 

To  formalise  our  idea  we  introduce  the  following  syntactic  categories: 


r 

V 

r 

<j 


e  TypeCA 
e  AnncA 
e  RegCA 
€  SchemecA 


types 

annotations  (or  behaviours) 

regions 

type  schemes 
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Types  are  much  as  before  but  extended  with  a  unit  type  (for  the  unit  value) 
and  a  type  for  channels: 

r  ::=  a  |  bool  |  int  |  unit  |  t\  -4  ti  |  t  chan  r 
Type  variables,  a  G  TVar,  are  as  before. 

Behaviours  differ  from  the  annotations  and  effects  used  so  far  in  that  we  shall 
not  merely  use  union  for  combining  them: 

ip  ::=  yd  |  A  |  \vi+<p>2\  rec 0.(p 

|  ?  chan  r  |  spawn  ip  |  r!f  j  r?f 

Behaviour  variables,  f3  G  AVar,  are  as  before  and  the  behaviour  A  is  used  for 
atomic  actions  that  do  not  involve  communication;  in  a  sense  it  corresponds 
to  the  empty  set  in  previous  annotations  although  it  will  be  more  intuitive  to 
think  of  it  as  the  empty  string  in  regular  expressions  or  as  the  silent  action 
in  process  calculi.  The  behaviour  <pi ;  tp2  says  that  p\  takes  place  before  p>2 
whereas  ipi  +  p>2  indicates  a  choice  between  p\  and  p>2  (as  will  be  the  case 
for  the  conditional);  this  is  reminiscent  of  constructs  in  regular  expressions 
as  well  as  in  process  algebras.  The  construct  rec fi.tp  indicates  a  recursive 
behaviour  that  acts  as  given  by  <p  except  that  any  occurrence  of  (3  stands  for 
recfl.ip  itself. 

The  behaviour  f  chan  r  indicates  that  a  new  channel  has  been  allocated  over 
which  entities  of  type  f  can  be  communicated;  the  region  r  indicates  the  set 
of  program  points  (see  below)  where  the  creation  could  have  taken  place. 
The  behaviour  spawn  ip  indicates  that  a  new  process  has  been  generated  and 
that  it  operates  as  described  by  <p.  Next  r!f  indicates  that  a  value  is  sent 
over  a  channel  of  type  f  chan  r  and  r?f  indicates  that  a  value  is  received 
over  a  channel  of  that  type;  this  is  reminiscent  of  constructs  in  most  process 
algebras  (in  particular  CSP). 

Regions  have  a  bit  more  structure  than  in  Subsection  5.4.3  because  now  we 
shall  also  be  able  to  take  the  union  of  regions: 

r  ::=  {7r}  |  q  j  ri  Ur2  |  0 

Region  variables,  g  G  RVar,  are  as  before.  In  Subsection  5.4.3  the  static 
regions  were  used  to  ensure  that  at  run-time  data  would  be  allocated  in  the 
same  dynamic  regions;  here  regions  are  used  to  identify  the  set  {7Ti, •  •  ■  ,7r „} 
of  program  points  where  a  channel  might  have  been  created.  (So  program 
points  now  play  the  role  of  region  names.)  However,  these  regions  will  not 
appear  explicitly  in  the  syntax  of  expressions,  types  or  behaviours. 

Type  schemes  have  the  form 

5  V(Ci,---,Cn).r 
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where  ft,*  •  •,£„  is  a  (possibly  empty)  list  of  type  variables,  behaviour  vari¬ 
ables  and  region  variables;  if  the  list  is  empty  we  simply  write  r  for  V().r. 

Example  5.35  Returning  to  the  program  of  Example  5.34,  the  node  func¬ 
tion  is  intended  to  have  the  type  schema 

V'a,'b,'l,"l,"2.  ('a  -4  'b)  A  ('a  chan  "1)  A  ('b  chan  "2)  unit 
where  p  =  spawn(rec  *2.  ("l?'a;  '1;  "2!'b;  *2)) 

corresponding  to  the  function  argument  having  type  'a  'b,  the  input 
channel  having  type  'a  chan  "1  and  the  output  channel  having  type  'b  chan  "2. 
When  supplied  with  these  arguments  the  node  function  will  spawn  a  process 
that  recursively  will  read  on  the  input  channel,  execute  the  function  supplied 
as  its  parameter,  and  write  on  the  output  channel  -  this  is  exactly  what  is 
expressed  by  p. 

The  pipe  function  is  intended  to  have  the  type  schema 

V'a,'l,"l,"2.(('a  -^4  'a)  list  A  ('a  chan  ("l  U  {C})) 

-*4  ('a  chan  "2)  unit 

where  ip'  =  rec  *2.  (spawn(rec  '3.  (("1  U  {C})?'a;  A;  “2!'a;  l3)) 

4-  'a  chan  C;  spawn(rec  '4.  (("1  U  {C})?'a;  '1;  C!'a;  '4));  '2) 

where  the  first  summand  in  the  body  of  ip'  corresponds  to  the  then-branch 
where  node  is  called  with  the  identity  function  (which  has  behaviour  A)  and 
the  second  to  the  else-branch  of  the  conditional.  Here  we  see  that  a  channel 
is  created,  a  process  is  spawned  and  then  the  overall  behaviour  recurses.  We 
shall  return  to  these  types  schemes  after  presenting  the  typing  rules.  ■ 

Typing  judgements.  The  typing  judgements  for  the  Communication 
Analysis  will  be  of  the  form 

T  l~c  a  e  :  ct  &  ip 

where  the  type  environment  T  maps  variables  to  type  schemes  (or  types),  a 
is  the  type  scheme  (or  type)  for  the  expression  e,  and  p  is  the  behaviour  that 
may  arise  during  evaluation  of  e.  The  analysis  is  specified  by  the  axiom  and 
rules  of  Tables  5.16  and  5.17  and  have  many  points  in  common  with  those 
we  have  seen  before;  the  differences  are  explained  below. 

The  axioms  [con]  and  [var]  for  constants  and  variables  differ  from  the  similar 
axioms  in  Table  5.10  in  that  A  is  used  instead  of  0.  A  similar  remark  holds 
for  the  two  rules  [fn]  and  [fun]  for  functions.  In  the  rule  [opp]  for  function 
application  we  now  use  sequencing  to  express  that  we  first  evaluate  the  func¬ 
tion  part,  then  the  argument  and  finally  the  body  of  the  function.  In  the  rule 
[if\  for  conditional  we  additionally  use  choice  to  express  that  only  one  of  the 
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[con] 

T  1~ca  c  ■.  tc  k  A 

[var] 

T  Fca  x:d  k  A 

if  f  (x)  ~  a 

IM 

r[x  i->  tx]  h ca  e0  :  r0  k  p0 

T  CA  fn»  x  =>  e0  : 

Tx  To  &  A 

[fun] 

r[/  (->  Tx  f0][x  !->  Tx\  Fca  e0:?o  k  p0 

f  b  CA  fun*  f  x  = 

>  eo  :  tx  ?o  k  A 

[app] 

r  hCA  ei  :  ?2  r0  k  <pi  T  rCA  e2  :  r2 

k  P2 

T  FCa  ei  e2  :  f0  k  pi\P2',Po 

r  ,yi 

r  hCA  eo  '■  bool  k  (po  T  Fca  ei  :  r  k  q>\ 

r  h ca  e2  :  ?  k  p2 

Ivj 

T  l~c a  if  eo  then  e\  else  e2  :  f  k  <po;  (‘Pi  +  P2) 

[let] 

r  h CA  :  ai  k  <fi 

P[x  i->  di]  hCA  e2  :  f2 

k  P2 

r  Fca  let  x  = 

ei  in  e2  :  r2  &  <pi ; P2 

[op] 

f  h CA  ei  :  k  pi 

P  hCA  e2  :  tIp  k  p2 

f  h ca  ei  op  e2 

:  top  k  pi\P2\  A 

Table  5.16:  Communication  Analysis  (part  1). 


then-  and  else-branches  are  taken.  Then  the  rules  [Ze<]  and  [op]  should  be 
straightforward. 

The  axiom  [chan]  for  channel  creation  makes  sure  to  record  the  program 
point  in  the  type  as  well  as  the  behaviour,  the  rule  [spawn]  encapsulates  the 
behaviour  of  the  spawned  process  in  the  behaviour  of  the  construct  itself  and 
the  rules  [send]  and  [receive]  for  sending  and  receiving  values  over  channels 
indicate  the  order  in  which  the  arguments  are  evaluated  and  then  produce  the 
behaviour  for  the  axiom  taken.  The  rules  [seq]  and  [eh]  are  straightforward 
and  the  rules  [gen]  and  [ins]  are  much  as  in  Table  5.10. 

The  rule  [sufi]  for  subeffecting  and  subtyping  looks  like  the  one  in  Table  5.10 
but  involves  a  few  subtleties.  The  ordering  r  <  f '  on  types  is  given  by 

i  ^  i  t'i  <  n  T2  <  ?2  p  C  iff  ?  <?'  f '  <  T  rCr' 

7^  Y  y  t=2  T  T  <  T  chan  T 

and  is  similar  to  the  definition  in  Subsection  5.4.1:  T\  r2  is  contravariant 
in  fi  but  covariant  in  p  and  r2)  and  r  chan  r  is  both  covariant  in  f  (for 
when  a  value  is  sent)  and  contravariant  in  f  (for  when  a  value  is  received) 
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[chan] 

T  1~ca  channel*  :  9  chan  {7r}  k  9  chan  {7r} 

[spawn] 

r  I"ca  eo  '■  To  k  tpo 

r  (”ca  spawn  eo  :  unit  k  spawn  tpo 

[send] 

r  l~c a  ei  :  9  k  (pi  T  hcA  e2  :  9  chan  r-i  k  tp2 

T  hcA  send  e\  on  e2  :  unit  k  tpi\tp2',r2*dr 

[receive] 

r  hcA  e0  :  9  chan  r0  k  tp0 

T  hcA  receive  eo  :  9  k  tp0-,ro?9 

[se?] 

r  hCA  ei  :  ?1  k  tpi  r  hCA  e2  :  f2  k  ip2 

r  hcA  ej ;  e2  :  T2  k  *p\ ;  <p 2 

[ch] 

T  hcA  ch  :  9  chan  r  k  A  if  9  chan  r  =  T(ch) 

[suh] 

?  hCA  e  :9  k  tp  ^  ^ 

— -  if  r  <  t  and  ip  LI  ip' 

T  hcA  e  :  f '  k  <p' 

[gen] 

T  hcA  e  :9  k  ip 

f  hCA  c  :  V(Ci,  •  •  • ,  Cn)-9  k  ip 

if  Ci  i  •  •  •  i  Cn  do  not  occur  free  in  T  and  tp 

[ins] 

f  hcA  e  :  V(Cx,---,Cn).r  k  tp 

f  hCA  e  :  (9  9)  k  tp 
if  0  has  dom(6 )  C  {Ci,  •  •  • ,  Cn} 

Table  5.17:  Communication  Analysis  (part  2). 


and  it  is  covariant  in  r.  The  ordering  r  C  r'  means  that  r  is  “a  subset  of” 
of  r'  (modulo  UCAI)  just  as  what  was  the  case  for  the  effects  in  Section 
5.4.  Finally,  the  ordering  tp  C  tp'  on  behaviours  in  more  complex  than  before 
because  of  the  rich  structure  possessed  by  behaviours.  The  definition  is  given 
in  Table  5.13  and  will  be  explained  below.  Since  the  syntactic  categories  of 
types  and  behaviours  are  mutually  recursive  also  the  definitions  of  9  <  9' 
and  tp  C  tp'  need  to  be  interpreted  recursively. 

The  axiomatisation  of  tp  C  tp'  in  Table  5.18  ensures  that  we  obtain  a  preorder 
that  is  a  congruence  with  respect  to  the  operations  for  combining  behaviours. 
Furthermore,  sequencing  is  an  associative  operation  with  A  as  identity  and 
we  have  a  distributive  law  with  respect  to  choice.  It  follows  that  choice  is 
associative  and  commutative.  Next  the  axioms  for  recursion  allows  us  to 
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ipCip 

<£i  Q<P2  y>3  E  <p* 

<Pi;<pz  e  <P2;<P4 

<£i  Q  <£2 

spawn  (pi  E  spawn  y?2 

(vi  +  ¥>2);  ¥>3  e  (¥>i;¥>3)  +  (¥>2;  ¥>3) 
ip  E  A;</2  A;<£>  C  <p 

¥*i  E  ¥*i  +  ¥>2  ¥>2  E  ¥h  +  <£2 

rec/3.tp  E  v?[/3  1-4  recfl.p] 

t  <  t'  t1  t  r  Cr' 

?  chan  r  E  f '  chan  r' 

rl  Q  r2  7"x  <  7"2 
ri  !fi  E  r2!f2 


¥?i  Ey>2  ¥2  E  y3 

¥>1  E  ¥>3 

¥>i  E  y?2  y?3  E  y>4 

¥>1  +  <P3  E  ¥>2  +  ¥>4 

¥)i  E  ¥?2 

recp.tpi  E  rec0.(fi2 
(¥,i5¥>2);¥j3  E  ¥^i ;(<P2',<P3) 

(¥’i;¥’3)  +  (¥32;¥53)  E  (^1  +¥’2);¥>3 
E  <£>;  A  ¥);  A  E 

(£  +  <£>  E  (£ 

</3[/3  1-4  rec^.y)]  E  rec(3.<p 

ri  Cr2  r2  <  Tj 

n?fx  E  r2?f2 


Table  5.18:  Ordering  on  behaviours. 


unfold  the  rec-construct.  The  final  three  rules  clarify  how  behaviours  depend 
upon  types  and  regions:  r  chan  r  is  both  contravariant  and  covariant  in  r  and 
is  covariant  in  r  (just  as  was  the  case  for  the  type  r  chan  r);  r!r  is  covariant 
in  both  r  and  r  (because  a  value  is  sent)  whereas  r?f  is  covariant  in  r  and 
contravariant  in  f  (because  a  value  is  received).  There  is  no  explicit  law  for 
renaming  bound  behaviour  variables  as  we  shall  regard  rec /3.ip  as  being  equal 
to  rec/3'.y>'  whenever  they  are  a-equivalent. 

The  Communication  Analysis  in  Tables  5.16  and  5.17  differs  from  the  Region 
Inference  Analysis  of  Tables  5.12  and  5.13  in  that  there  is  no  analogue  of  the 
rule  [ region }  where  an  Observe  function  is  used  to  reduce  the  annotation  to 
what  is  visible  from  the  outside.  The  reason  is  that  the  Communication  Anal¬ 
ysis  is  intended  to  record  all  the  side  effects  (in  the  form  of  communications) 
that  take  place  during  computation. 

Example  5.36  Returning  to  the  program  of  Example  5.35  we  can  now 
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verify  that  the  node  function  can  be  given  the  type: 

('a  'b)  -4  ('a  chan  "l)  ('b  chan  "2)  unit 

where  p  =  spawn(rec  *2.  ("l?'a;  '1;  "2!'b;  3)) 

We  use  the  rules  [fun ]  and  [suft]  of  Tables  5.16  and  5.17  together  with  the 
axiom  tp[0  h*  r ecfi.tp]  C  rec  )3.<p  of  Table  5.18.  Then  the  rule  [gen]  allows  us 
to  obtain  the  type  schema  given  in  Example  5.35. 

Turning  to  the  pipe  function  we  first  note  that  it  can  be  given  a  type  of  the 
form 

(('a  'a)  list)  ('a  chan  ("l  U  {C}))  ('a  chan  "2)  -^4  unit 

where  the  regions  for  the  input  and  local  channels  are  “merged”  because  they 
can  both  be  used  as  input  channels  in  a  call  to  pipe  whereas  the  region  for 
the  output  channel  is  always  kept  separate.  The  behaviour  p'  is  of  the  form 

rec  l2.  (spawn(rec  '3.  (("1  U  {C})?'a;  A;  "2!'a;  3)) 

+  'a  chan  C;  spawn(rec '4.  (("1 U  {C})?'a;  '1;  C!'a;'4));  'S) 

because  in  the  then-branch  the  input  channel  for  node  has  type  'a  chan  ("1 U 
{C})  and  the  output  channel  has  type  'a  chan  "2,  whereas  in  the  else-branch 
the  input  channel  for  node  has  type  'a  chan  ("1U{C})  and  the  output  channel 
has  type  'a  chan  {C}  (as  well  as  'a- chan  ("l  U  {C})).  The  rule  [gen]  allows  us 
to  obtain  the  type  schema  displayed  in  Example  5.35.  ■ 


Concluding  Remarks 

Control  Flow  Analysis.  The  literature  [37,  38,  54, 11]  contains  many 
formulations  of  non-standard  type  systems  aiming  at  performing  Control 
Flow  Analysis.  The  formulation  presented  in  Section  5.1  uses  a  particularly 
simple  set  of  techniques  where  types  are  annotated  but  there  is  no  additional 
effect  component  nor  is  there  any  coverage  of  polymorphism  or  subtyping. 
Although  there  is  no  explicit  clause  for  subeffecting  in  the  manner  of  Section 
5.4,  we  regard  the  formulation  as  a  subeffecting  analysis  because  the  rules  for 
function  abstraction  allow  to  increase  the  annotation  on  the  function  arrow 
in  much  the  same  way  as  is  the  case  in  subeffecting  (and  in  much  more  re¬ 
stricted  ways  than  holds  for  subtyping;  see  also  Exercise  5.12).  References 
for  type  systems  with  subtyping  include  [43,  42,  81]  as  well  as  the  more  ad¬ 
vanced  [63,  125,  126]  that  also  deal  with  polymorphism.  To  allow  a  general 
treatment  of  subtyping,  these  papers  generally  demand  constraints  to  be  an 
explicit  part  of  the  inference  system  unlike  what  was  done  in  Section  5.1.  In¬ 
deed,  the  formulation  of  Section  5.1  allows  only  shape  conformant  subtyping, 
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where  the  underlying  type  system  does  not  make  use  of  any  form  of  subtyp¬ 
ing,  and  is  thus  somewhat  simpler  than  atomic  subtyping,  where  an  ordering 
is  imposed  upon  base  types,  and  general  subtyping,  where  an  ordering  may 
be  imposed  between  arbitrary  types. 

The  semantic  correctness  of  the  Control  Flow  Analysis  established  in  Section 
5.2  is  expressed  as  a  subject  reduction  result  but  formulated  for  a  Natural 
Semantics  (rather  than  a  Structural  Operational  Semantics);  this  approach 
to  semantic  correctness  has  a  rather  long  history  [86,  88,  144].  The  Moore 
family  result  about  the  set  of  typings  is  inspired  by  the  ideas  of  [86]  and  is 
included  so  as  to  stress  the  fundamental  role  played  by  partial  orders  in  all 
of  the  approaches  to  program  analysis  considered  in  this  book;  it  also  relates 
to  the  study  of  principal  types  in  type  systems. 

The  development  of  a  syntactically  sound  and  complete  algorithm  for  the 
Control  Flow  Analysis  in  Section  5.3  is  based  on  the  ideas  in  [69,  143,  132, 
133,  134];  Mini  Project  5.1  is  based  on  [134].  The  basic  idea  is  to  ensure 
that  the  algorithm  operates  on  a  free  algebra  by  restricting  annotations  to  be 
annotation  variables  only  (the  concept  of  simple  types)  and  by  recording  a  set 
of  constraints  for  the  meaning  of  the  annotation  variables;  in  our  case  this  is 
particularly  straightforward  because  the  Control  Flow  Analysis  does  not  deal 
with  polymorphism.  Our  development  differs  somewhat  from  that  of  [42,  81] 
that  deal  with  the  more  advanced  notions  of  atomic  subtyping  and  general 
subtyping.  A  different  approach,  not  studied  here,  would  be  to  dispense  with 
simple  types  and  constraints  and  instead  use  techniques  for  unifying  types  in 
a  non-free  algebra  [124]. 

Restricted  effects.  The  Type  and  Effect  Systems  presented  in  Section 
5.4  all  share  the  important  property  (also  holding  for  the  type  system  in 
Section  5.1)  that  no  type  information  is  recorded  in  the  effects  and  that  the 
shape  of  the  type  information  cannot  be  influenced  by  the  effects.  All  systems 
included  a  proper  effect  component  and  thereby  illustrated  the  diversity  of 
effects;  some  pioneering  papers  in  Type  and  Effect  Systems  are  [67,  77,  68,  69]. 
At  the  same  time  we  illustrated  a  number  of  design  considerations  to  be  taken 
into  account  when  devising  a  Type  and  Effect  System:  whether  or  not  to 
incorporate  subeffecting,  subtyping,  polymorphism,  polymorphic  recursion, 
whether  or  not  types  are  allowed  to  be  influenced  by  effects  (which  is  not  the 
case  in  Sections  5.4  and  5.1),  and  whether  or  not  constraints  are  an  explicit 
part  of  the  inference  system  (as  is  implicitly  the  case  in  Subsection  5.4.3). 
However,  it  would  be  incorrect  to  surmise  that  the  selection  of  components  are 
inherently  linked  to  the  example  analysis  where  they  were  illustrated.  Rather, 
the  techniques  needed  for  semantic  correctness  and  for  syntactic  soundness 
and  completeness  depend  heavily  on  the  particular  selection  of  components; 
some  are  straightforward  to  deal  with  whereas  others  are  beyond  state-of- 
the-art. 

The  Side  Effect  Analysis  presented  in  Subsection  5.4.1  illustrated  the  use 
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of  subeffecting  and  subtyping,  but  did  not  incorporate  polymorphism,  there 
were  no  constraints  in  the  inference  system,  and  the  effects  did  not  influence 
the  types.  This  system  is  sufficiently  simple  that  semantic  soundness  may 
be  established  using  the  techniques  of  Section  5.2.  If  the  rule  for  subtyping 
was  omitted  then  also  the  techniques  developed  in  Section  5.3  would  suffice 
for  obtaining  a  sound  and  complete  inference  algorithm.  The  presence  of 
the  rule  for  subtyping  naturally  leads  to  a  two  stage  implementation  process: 
first  the  underlying  types  are  inferred  and  next  the  constraints  on  effects 
(or  annotations)  are  determined  [134,  136].  This  works  because  we  restrict 
ourselves  to  shape  conformant  subtyping  where  effects  do  not  influence  the 
type  information.  However,  adding  polymorphism  to  this  development  would 
dramatically  increase  the  complexity  of  the  development  (see  below). 

The  Exception  Analysis  presented  in  Subsection  5.4.2  illustrated  the  use  of 
subeffecting,  subtyping  and  polymorphism,  but  there  were  no  constraints  in 
the  inference  system,  and  the  effects  did  not  influence  the  types.  Semantic 
soundness  is  a  bit  more  complex  than  in  Section  5.2  because  of  the  polymor¬ 
phism  but  the  techniques  of  [135,  132,  133,  8]  suffice.  For  the  development 
of  a  syntactically  sound  and  complete  inference  algorithm  one  may  take  the 
two  stage  approach  described  above  [134,  136];  as  before,  it  works  because 
we  restrict  ourselves  to  shape  conformant  subtyping  where  effects  do  not 
influence  the  type  information.  Alternatively,  one  may  use  more  powerful 
techniques  [143,  132,  133,  97]  that  even  allow  to  include  type  information 
inside  effects;  this  amounts  to  an  extension  of  the  approach  of  Section  5.3 
and  will  be  explained  below. 

The  Region  Inference  analysis  presented  in  Subsection  5.4.3  illustrated  the 
use  of  polymorphic  recursion  as  far  as  the  effects  are  concerned,  there  were 
implicitly  constraints  in  the  inference  system  (via  the  dot  notation  on  func¬ 
tion  arrows),  but  still  the  effects  cannot  influence  the  types.  The  presentation 
is  mainly  based  on  [137]  but  adapted  to  the  Fun  language  and  the  style  of 
presentation  used  elsewhere  in  this  chapter.  To  obtain  effects  that  are  as 
small  as  possible  the  inference  system  uses  “effect  masking”  (developed  in 
[77,  132,  133])  for  removing  internal  components  of  the  effect:  effect  compo¬ 
nents  that  only  deal  with  regions  that  are  not  externally  visible.  Semantic 
correctness  of  the  inference  system  can  be  shown  using  the  approach  of  [138]. 
For  the  development  of  a  syntactically  sound  inference  algorithm  one  may 
once  more  take  the  two  stage  approach  described  above;  the  first  stage  (or¬ 
dinary  type  inference)  is  standard  and  the  second  stage  is  considered  in  [136] 
where  algorithm  <S  generates  effect  and  region  variables  and  algorithm  K 
deals  with  the  complications  due  to  polymorphic  recursion  (for  effects  and 
regions  only).  The  inference  algorithm  is  proved  syntactically  sound  but  is 
known  not  to  be  syntactically  complete;  indeed,  obtaining  an  algorithm  that 
is  syntactically  sound  as  well  as  complete,  seems  beyond  state-of-the-art. 
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General  effects.  One  way  to  make  effects  more  expressive  is  to  allow 
type  information  inside  the  effects  so  that  the  shape  of  the  type  information 
can  be  influenced  by  the  effects.  This  idea  occurred  already  in  [143,  132,  133] 
for  an  extended  Side  Effect  Analysis  making  use  of  polymorphism  and  subef¬ 
fecting  (but  not  subtyping);  this  work  attempted  to  “generalise”  previous 
work  based  on  the  idea  of  expansive  expressions  and  imperative  versus  ap¬ 
plicative  type  variables  [135,  131].  As  already  indicated,  semantic  soundness 
amounts  to  an  extension  of  the  techniques  of  Section  5.2  as  presented  in 
[135,  132,  133,  8]. 

The  two  stage  approach  no  longer  works  for  obtaining  an  inference  algorithm 
because  the  effects  are  used  to  control  the  shape  of  the  underlying  types 
in  the  form  of  which  type  variables  are  included  in  a  polymorphic  type. 
This  suggests  extending  the  techniques  of  Section  5.3  in  that  special  care 
needs  to  be  taken  when  deciding  the  variables  over  which  to  generalise  when 
constructing  a  polymorphic  type.  The  main  idea  is  that  the  algorithm  needs 
to  consult  the  constraints  in  order  to  determine  a  larger  set  of  forbidden 
variables  than  those  directly  occurring  in  the  type  environment  or  the  effect; 
this  can  be  formulated  as  a  downwards  closure  with  respect  to  the  constraint 
set  [143,  97]  or  by  taking  a.  principal  solution  of  the  constraints  into  account 
[132,  133]. 

Adding  subtyping  to  this  development  dramatically  increases  the  complexity 
of  the  development.  The  integration  of  atomic  subtyping  (a  generalisation 
of  shape  conformant  subtyping),  polymorphism  and  subeffecting  is  done  in 
[97,  103,  8]  that  establishes  semantic  soundness  and  develops  an  inference 
algorithm  that  is  proved  syntactically  sound;  extensions  of  this  development 
incorporate  a  syntactic  completeness  result  (see  the  discussion  of  [6]  below). 
This  work  went  a  long  way  towards  integrating  the  techniques  for  polymor¬ 
phism  and  subeffecting  (but  no  subtyping)  from  Effect  Systems  [143, 132, 133] 
with  the  techniques  for  polymorphism  and  subtyping  (but  no  effects)  from 
Type  Systems  [63,  125,  126]. 

Another  way  to  make  effects  more  expressive  is  to  let  them  contain  infor¬ 
mation  about  the  temporal  order  and  causality  of  actions,  rather  than  just 
being  an  unordered  set  of  possibilities.  In  Section  5.5  we  considered  the  task 
of  extracting  behaviours  (reminiscent  of  terms  in  a  process  algebra)  from  pro¬ 
gram  in  Concurrent  ML  by  means  of  a  Type  and  Effect  System;  here  effects 
(the  behaviours)  have  structure,  they  may  influence  the  type  information, 
there  are  no  explicit  constraints  in  the  inference  system  (although  this  is  the 
case  in  more  advanced  developments  [6]),  and  there  are  inference  rules  for 
subeffecting  and  (atomic)  subtyping.  These  ideas  first  occurred  in  [91,  92] 
(not  involving  polymorphism)  and  in  [100,  101,  7]  (involving  polymorphism); 
our  presentation  in  Section  5.5  is  mainly  based  on  [100,  101]  with  ingredients 
from  [91,  92].  We  refer  to  [6]  for  a  comprehensive  account  of  a  more  ambitious 
development  where  the  inference  system  is  massaged  so  as  to  facilitate  devel- 
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oping  a  syntactically  sound  and  complete  inference  algorithm;  this  includes 
having  explicit  constraints  in  the  inference  system  as  is  usually  the  case  in 
type  systems  that  make  use  of  subtyping.  An  application  to  the  validation 
of  embedded  systems  is  presented  in  [98]. 

Other  developments.  All  of  the  formulations  presented  in  this  chap¬ 
ter  have  had  a  number  of  common  features:  to  the  extent  that  polymorphism 
has  been  incorporated  it  has  been  based  on  the  Hindley/Milner  polymor¬ 
phism  also  found  in  Standard  ML,  there  has  been  no  subtyping  involved  in 
the  underlying  type  system,  and  there  has  been  no  treatment  of  conjunction 
or  disjunction  types  as  in  [12,  13,  61,  62].  Also  all  of  the  formulations  have 
expressed  safety  properties:  if  a  certain  point  is  reached  then  certain  infor¬ 
mation  will  hold;  liveness  properties  in  the  form  of  adding  annotations  that 
indicate  whether  or  not  functions  can  be  assumed  to  be  total  was  considered 
in  [93]. 

Finally,  linking  up  with  the  development  of  Chapter  4  on  Abstract  Interpre¬ 
tation,  it  is  possible  to  allow  annotations  to  be  elements  of  a  complete  lattice 
(that  is  possibly  of  finite  height  as  in  Monotone  Frameworks),  and  it  may 
be  profitable  to  describe  Type  and  Effect  Systems  using  the  framework  of 
Abstract  Interpretation  [82,  26]. 


Mini  Projects 

Mini  Project  5.1  A  Call-Tracking  Analysis 

Consider  a  Type  and  Effect  System  for  Call-Tracking  Analysis:  it  has  judge¬ 
ments  of  the  form 

T  1~ct  e  :  t  &  tp 

where  y  denotes  the  set  of  functions  that  may  be  called  during  the  evaluation 
of  e  (and  similarly  for  the  annotations  on  function  arrows). 

1.  Formulate  an  inference  system  with  subeffecting;  next  add  subtyping 
and  finally  add  polymorphism. 

Next  consider  the  inference  system  with  subeffecting  only: 

2.  Modify  the  Natural  Semantics  of  Table  5.4  such  that  semantic  correct¬ 
ness  can  be  stated  for  the  analysis  and  prove  that  the  result  holds. 

3.  Devise  an  algorithm  for  Call-Tracking  Analysis  and  prove  that  it  is 
syntactically  sound  (and  complete). 


For  the  more  ambitious:  can  you  also  deal  with  subtyping  and/or  polymor¬ 
phism?  ■ 
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Mini  Project  5.2  Data  Structures 

As  in  Mini  Project  3.2  we  shall  now  extend  the  language  with  more  general 
data  structures  and  consider  how  to  modify  the  Control  Flow  Analysis  (Table 
5.2)  so  as  to  track  the  creation  points. 

Pairs.  To  accommodate  pairs  we  extend  the  syntax  as  follows: 

t  ::=  •  •  •  |  ?i  ?2 

e  ::=  |  Pair,r(ei,e2)  j  (case  eo  of  Pair^i,^)  =>  ei) 

Here  Pair  is  a  binary  constructor  and  the  corresponding  case-expression  does 
not  need  an  or-component  as  in  Mini  Project  3.2.  As  an  example,  consider 
the  following  program  for  “sorting”  a  pair  of  integers: 

let  srt  =  fnx  x  =>  case  x  of  Pair(y,z)  => 

if  y<z  then  x  else  PairB(z,y) 
in  srt(PairA(n,m)) 

Here  the  pair  returned  with  be  constructed  at  A  if  the  value  of  n  is  smaller 
than  the  value  of  m  and  at  B  otherwise.  The  overall  type  is  int  xlA,Bl  int. 

1.  Modify  the  Control  Flow  Analysis  of  Table  5.2  to  track  the  creation 
points  of  pairs. 

2.  Extend  the  Natural  Semantics  of  Table  5.4  and  augment  the  proof  of 
semantic  correctness  (Theorem  5.9). 

3.  Extend  the  algorithms  Wcfa  and  Ucfa  and  augment  the  proof  of  syn¬ 
tactic  soundness  and  completeness  (Theorems  5.20  and  5.21). 

Lists.  To  accommodate  lists  we  extend  the  syntax  as  follows: 
t  ::=  •  •  •  |  f  list'*’ 

e  ::=  •••  |  Cons^(ei,e2)  |  Nil*  |  (case  eo  of  Consul, X2)  =>  e.\  or  e-i) 

Now  perform  a  similar  development  as  the  one  you  performed  for  pairs. 

For  the  more  ambitious:  can  you  give  a  more  general  treatment  of  algebraic 
types  in  the  manner  of  Mini  Project  3.2?  ■ 
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Mini  Project  5.3  A  Prototype  Implementation 

In  this  mini  project  we  shall  implement  the  Control  Flow  Analysis  considered 
in  Sections  5.1  and  5.3.  As  implementation  language  we  shall  choose  a  func¬ 
tional  language  as  Standard  ML  or  Haskell.  We  can  then  define  a  suitable 
data  type  for  Fun  expressions  as  follows: 

type  var  =  string 

type  point  =  int 

datatype  const  =  Num  of  int  |  True  |  False 

datatype  exp  =  Const  of  const  |  Var  of  var  |  Fn  of  point  *  var  *  exp 

|  Fun  of  point  *  var  *  var  *  exp  \  App  of  exp  *  exp 

j  If  of  exp  *  exp  *  exp  |  Let  of  var  *  exp  *  exp 
|  Op  of  string  *  exp  *  exp 

Now  proceed  as  follows: 

1.  Define  data  types  for  simple  types  and  simple  substitutions  and  imple¬ 
ment  the  function  Ucfa  of  Table  5.7. 

2.  Define  data  types  for  simple  type  environments  and  constraint  sets  and 
implement  the  function  Wcfa  of  Table  5.8. 

3.  Define  data  types  for  typesrand  type  environments  and  implement  a 
function  that  pretty  prints  the  result  in  the  manner  of  Subsection  5.3.4: 
type  variables  must  get  instantiated  to  int  and  annotation  variables  to 
the  least  solution  to  the  constraints. 

Test  your  implementation  on  selected  examples.  ■ 


Exercises 

Exercise  5.1  Consider  the  following  expression: 

let  f  =  fnx  x  =>  x  1; 
g  =  fny  y  =>  y+2; 
h  =  fnz  z  =>  z+3 
in  (f  g)  +  (f  h) 

Use  Table  5.1  (the  underlying  type  system)  to  obtain  a  type  for  this  expres¬ 
sion;  what  types  do  you  use  for  f ,  g  and  h?  Next  use  Table  5.2  (Control  Flow 
Analysis)  to  obtain  the  annotated  type  of  this  expression;  what  annotated 
types  do  you  use  for  f ,  g  and  h?  ■ 


350 


TYPE  AND  EFFECT  SYSTEMS 


Exercise  5.2  Consider  the  following  variation  of  Fun  where  function  def¬ 
initions  explicitly  involve  type  information  as  in  fn*  x  :  tx  =>  eo  and  fun*  /  : 
( tx  -*  ro)  x  =>  eo.  Modify  Table  5.1  accordingly  and  prove  that  the  resulting 
type  system  is  deterministic:  T  I~ul  e  :  n  and  T  Pul  e  •  ri  imply  t\  =  r2.  ■ 

Exercise  5.3  Consider  the  inclusion  ipi  C  y>2  between  effects  that  was 
discussed  in  Subsections  5.4.1  and  5.2.3.  Give  an  axiomatisation  of  ipi  C  <p2 
such  that  ip x  C  (p2  holds  if  and  only  if  the  set  of  elements  mentioned  in  <p\  is 
a  subset  of  the  set  of  elements  mentioned  in  •  ■ 

Exercise*  5.4  In  Example  5.4  we  showed  how  to  record  the  annotated 
type  information  in  a  form  close  to  that  considered  in  Chapter  3.  To  make 
this  precise  suppose  that  expressions  of  Fun  are  simultaneously  labelled  as 
in  Chapters  3  and  5: 

e  tl 

t  ::=  c  |  x  |  fn*  x  =>  eo  |  fun*  /  x  =>  eo  |  e\  e2 

|  if  eo  then  e\  else  e2  |  let  x  =  e\  in  e2  |  e\  op  e2 

Next  modify  Table  5.2  so  as  to  define  a  judgement 

P,C-,T  Pcfa  fi  :  t  (5.2) 

where  the  idea  is  that 

•  C(i)  =  Ti  ensures  that  all  judgements  p,  C;  F'  Pcfa  t*  :  t'  in  (5.2)  have 
r'  —  Ti,  and 

-  ^  . 

•  p(x)  =  rx  ensures  that  all  judgements  p,  C;  T'  Pcfa  ar  :  f'  in  (5.2)  have 
9'  =  Tx. 

Check  that  (5.2)  holds  for  the  expression  in  Example  5.4  when  we  take  C(l)  = 
7y,  C( 2)  =  tv  tv,  C( 3)  =  int,  C(4)  =  t\,  C( 5)  =  7v,  p(x)  =  t\  and 

p{y)  =  int.  ■ 

Exercise  5.5  Consider  adding  the  following  inference  rule  to  Table  5.2 
(Control  Flow  Analysis) 

r  Pcfa  ei  :  f2  fo  f  Pcfa  e2  :%  . 

- ^ -  if  tp  =  0 

T  Pcfa  zi  :  T- 

where  ±^o  is  the  least  element  of  Type[ro]  and  ro  =  [_?oJ.  Explain  what  this 
rule  does  and  determine  whether  or  not  Theorem  5.9  (semantic  correctness) 
continues  to  hold.  ■ 
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Exercise  5.6  In  Section  5.2  we  equipped  Fun  with  a  call-by-value  se¬ 
mantics.  An  alternative  would  be  to  use  a  call-by-name  semantics.  It  can  be 
obtained  as  a  simple  modification  of  the  semantics  of  Table  5.4  by  changing 
rule  [ app ]  such  that  the  argument  is  not  evaluated  before  the  substitution 
takes  place  and  similarly  changing  rule  [let].  Make  these  changes  to  Table  5.4 
and  show  that  the  correctness  result  (Theorem  5.9)  still  holds  for  the  analysis 
of  Table  5.2. 

What  does  that  tell  us  about  the  precision  of  the  analysis?  ■ 

Exercise  5.7  Prove  Fact  5.17  (the  syntactic  soundness  and  completeness 
of  Robinson  unification).  ■ 

Exercise  5.8  Consider  the  partial  ordering  f  <  ?'  on  the  annotated  types 
of  Section  5.1  that  is  defined  by: 

ft  <  n  r2  <  ?2  ipC  <p' 

f  i  ?2  <  T[  ?2 

We  shall  say  that  this  ordering  treats  ?i  -£»  r2  covariantly  in  ip  and  t2  but 
contravariantly  in  fy ;  this  is  in  line  with  the  subtype  ordering  considered  in 
Section  5.4  but  differs  form  the  partial  ordering  rCf'  considered  in  Section 
5.2. 

Show  that  (Type[r],  <)  is  a  complete  lattice  for  all  choices  of  the  underlying 
type  t  €  Type.  Next  investigate  whether  or  not  an  analogue  of  Proposition 
5.12  holds  for  this  ordering. 

Finally  reconsider  the  decision  to  let  8".(a)  in  Subsection  5.3.4  be  the  least 
element  of  (Type[r],C);  would  it  be  preferable  to  let  d'^(a)  be  the  least 
element  of  (Type[r],  <)  or  (Type[r],  >)?  ■ 

Exercise*  5.9  Suppose  that 

WUL([  ],funF  /  x  =>  e0)  =  (ax  -¥  a0,6) 

where  ax  and  ao  are  distinct  type  variables.  Let  e  be  an  arbitrary  correctly 
typed  closed  expression,  i.e.  [  ]  Pul  e  :  r  for  some  r  and  show  that  the  call 

(funF  /  x  =>  eo)  e 

cannot  terminate.  (Hint:  use  Fact  5.6,  Theorems  5.9,  5.20  and  5.21  and  that 
WUL  is  syntactically  sound.)  ■ 

Exercise  5.10  Formulate  what  it  means  for  the  Side  Effect  Analysis  of 
Table  5.9  to  be  semantically  correct;  this  involves  modifying  the  Natural 
Semantics  of  Table  5.4  to  deal  with  the  store  and  to  record  the  side  effects. 
(Proving  the  result  would  require  quite  some  work.)  ■ 
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Exercise  5.11  Suppose  that  the  language  of  Subsection  5.4.1  has  a  call- 
by-name  semantics  rather  them  a  call-by-value  semantics.  Modify  the  Side 
Effect  Analysis  of  Table  5.9  accordingly.  ■ 

Exercise  5.12  We  shall  now  illustrate  the  concept  of  proof  normalisation 
for  the  Side  Effect  Analysis  of  Subsection  5.4.1;  for  this  we  shall  assume  tnat 
Table  5.9  does  not  include  the  combined  rule  for  subeffecting  and  subtyping 
but  only  the  rule  for  subeffecting. 

For  this  system  one  can  dispense  with  an  explicit  rule  for  subeffecting  by 
integrating  its  effects  into  all  other  rules;  this  can  be  done  by  adding  a  “U tp'n 
to  all  effects  occurring  in  the  conclusions  of  all  axioms  and  rules.  Do  this  and 
argue  that  exactly  the  same  judgements  are  provable  in  the  two  systems. 

A  further  variation  is  only  to  incorporate  “U <p,n  where  it  is  really  needed:  in 
all  axioms  and  in  the  rules  for  function  abstraction.  Do  this  and  argue  that 
once  more  exactly  the  same  judgements  are  provable  in  the  two  systems. 

What  you  have  performed  amounts  to  proof  normalisation:  whenever  one 
has  an  inference  system  with  a  number  of  syntax  directed  rules  and  axioms 
and  at  least  one  rule  that  is  not  syntax  directed,  it  is  frequently  possible  to 
restrict  the  use  of  the  non  syntax  directed  rules.  In  this  way  the  structure 
of  the  inference  trees  comes  closer  to  the  structure  of  the  syntax  trees  and 
this  is  often  helpful  for  proving  semantic  correctness  and  is  a  useful  starting 
point  for  developing  inference  algorithms.  ■ 

Exercise  5.13  Consider  the  rule  [ handle ]  in  the  Exception  Analysis  of 
Table  5.10.  Would  the  analysis  still  be  semantically  correct  if  we  replaced  it 
by  the  following  two  rules: 

r  Fes  ei  :  r  &  T  Fes  '■  t  &  <p2 
T  Fes  handle  s  as  ei  in  e?  :  9  &  <p2 
if  s  ^  v?2  and  AV{<p 2)  =  0 

r  FEs  ex  :  f  &  yi  T  Fes  e2  :  f  k  y>2 
T  Fes  handle  sas  ej  in  e2  :  f  &  ipi  U  (<^2\{s}) 
if  s  €  y>2  or  AVfa)  ^  0 

Here  s  €  <p 2  means  {s}  C  ip2  and  AV(ip 2)  is  the  set  of  annotation  variables 
in  ip2-  m 

Exercise  5.14  Consider  the  Exception  Analysis  of  Table  5.10  and  change 
the  rule  [let]  to 

r  FEs  ei  :  gj  fc  tp\  d\]  Fes  e2  :  ?2  &  <p 2 

T  Fes  let  x  =  e\  in  e2  :  ?2  &  ^1  U  <^2 
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and  perforin  similar  changes  in  [if\,  [raise],  [handle]  and  [su£>];  do  not  forget  to 
define  the  meaning  of  r  <  f1.  Clearly  the  new  system  is  at  least  as  powerful 
as  Table  5.10  but  is  it  more  powerful?  (Hint:  Consider  the  places  where  [<?en] 
and  [ins]  can  be  used  in  Table  5.10.)  ■ 
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Chapter  6 

Algorithms 

(This  material  remains  to  be  integrated.) 
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Appendix  A 

Partially  Ordered  Sets 


Partially  ordered  sets  and  complete  lattices  play  a  crucial  role  in  program 
analysis  and  in  this  appendix  we  shall  summarise  some  of  their  properties. 
We  review  the  basic  approaches  for  how  to  construct  complete  lattices  from 
other  complete  lattices  and  state  the  central  properties  of  partially  ordered 
sets  satisfying  the  Ascending  Chain  and  Descending  Chain  Conditions.  We 
then  review  the  classical  results  about  least  and  greatest  fixed  points. 


A.l  Basic  Definitions 

Partially  ordered  set.  A  partial  ordering  is  a  relation  C:  L  x  L 
{true,  false}  that  is  reflexive  (i.e.  VI  :  l  C  l),  transitive  (i.e.  Vfi,  Z2,  ^3  :  l\  C 
l2  A  I2  C  13  =>■  h  C  13),  and  anti-symmetric  (i.e.  VI1J2  ■  h  E  h  A  h  E  h  => 
li  =  I2).  A  partially  ordered  set  ( L ,  C)  is  a  set  L  equipped  with  a  partial 
ordering  C  (sometimes  written  C/,).  We  shall  write  I2  3  h  for  l\  C  I2  and 
h  C  I2  for  li  C  I2  A  l\  ^  Z2. 

A  subset  Y  of  L  has  l  €  L  as  an  upper  bound  if  Vi'  £  Y  :  V  C  l  and  as 
a  lower  bound  if  VI'  €  Y  :  V  □  l.  A  least  upper  bound  l  of  Y  is  an  upper 
bound  of  Y  that  satisfies  l  C  10  whenever  lo  is  another  upper  bound  of  Y ; 
similarly,  a  greatest  lower  bound  l  of  Y  is  a  lower  bound  of  Y  that  satisfies 
10  E  l  whenever  lo  is  another  lower  bound  of  Y.  Note  that  subsets  Y  of  a 
partially  ordered  set  L  need  not  have  least  upper  bounds  nor  greatest  lower 
bounds  but  when  they  exist  they  are  unique  (since  C  is  anti-symmetric)  and 
they  are  denoted  |J  Y  and  n^>  respectively.  Sometimes  [J  is  called  the  join 
operator  and  [~~|  the  meet  operator  and  we  shall  write  l\  UI2  for  jj{li ,  I2}  and 
similarly  l\  n  I2  for 

Complete  lattice.  A  complete  lattice  L  -  ( L , C)  =  ( L , C, LJ,fl5  -L,  T) 
is  a  partially  ordered  set  ( L ,  C)  such  that  all  subsets  have  least  upper  bounds 
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{3} 

{2,3} 


Figure  A.l:  Two  complete  lattices. 


as  well  as  greatest  lower  bounds.  Furthermore,  _L  =  j_J0  =  [—|^-,is  the  least 
element  and  T  =  fl®  =  U-^  is  the  greatest  element. 

Example  A.l  If  L  =  {V(S),C)  for  some  set  S  then  C  is  C  and  (JY  = 
U  Y,  riY  =  f|^,  J-  =  0  and  T  =  5.  If  L  =  ( V(S ),  D)  then  C  is  D  and 
IJF  =  f)Y,  f\Y  =  U^,  -L  =  S  and  T  =  0. 

Hence  ( V(S ),  C)  as  well  as  (V(S),  D)  are  complete  lattices.  In  the  case  where 
S  =  {1, 2, 3}  the  two  complete  lattices  are  shown  on  Figure  A.l;  these  draw¬ 
ings  are  often  called  Hasse  diagrams.  Here  a  line  “going  upwards”  from  some 
li  to  some  h  means  that  Zj  C  h;  we  do  not  draw  lines  that  follow  from 
reflexivity  or  transitivity  of  the  partial  ordering.  ■ 


Lemma  A. 2  For  a  partially  ordered  set  L  =  (L,  C)  the  claims 

(i)  L  is  a  complete  lattice, 

(ii)  every  subset  of  L  has  a  least  upper  bound,  and 

(iii)  every  subset  of  L  has  a  greatest  lower  bound 

are  equivalent.  ■ 

Proof  Clearly  (i)  implies  (ii)  and  (iii).  To  show  that  (ii)  implies  (i)  let  Y  CL  and 
define 


(~]Y  =  |J{Z€L|W'e  Y-.lCl'}  (A.l) 

and  let  us  prove  that  this  indeed  defines  a  greatest  lower  bound.  All  the  elements 
of  the  set  on  the  right  hand  side  of  (A.l)  are  lower  bounds  of  Y  so  clearly  (A.l) 
defines  a  lower  bound  of  Y.  Since  any  lower  bound  of  Y  will  be  in  the  set  it  follows 
that  (A.l)  defines  the  greatest  lower  bound  of  Y.  Thus  (i)  holds. 
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To  show  that  (iii)  implies  (i)  we  define  |Jy  =  f"IO  6  L  |  VI'  €  Y  :  l'  C  I}. 
Arguments  analogous  to  those  above  show  that  this  defines  a  least  upper  bound 
and  that  (i)  holds.  ■ 

Moore  family.  A  Moore  family  is  a  subset  Y  of  a  complete  lattice 
L  =  (L,  C)  that  is  closed  under  greatest  lower  bounds:  VY'  C  Y  :  f~|Y'  €  Y. 
It  follows  that  a  Moore  family  always  contains  a  least  element,  and 
a  greatest  element,  fl0>  which  equals  the  greatest  element,  T,  from  L;  in 
particular,  a  Moore  family  is  never  empty. 

Example  A. 3  Consider  the  complete  lattice  ( V(S ),  C)  of  Figure  A.l  (a). 
The  subsets 


{{2},  {1, 2},  {2, 3},  {1, 2, 3}}  and  {0,  {1, 2, 3}} 


are  both  Moore  families,  whereas  none  of 


{{!},  {2}}  and  {0,  {1},{2},{1,2}} 


are. 


■ 


Properties  of  functions.  A  function  /  :  L\  — ►  L2  between  partially 
ordered  sets  L\  —  (L\ ,  Cj)  and  L2  =  (L2,  C2)  is  surjective  (or  onto  or  epic) 
if 


VZ2  €  L2  :  3Zi  e  Lx  :  f(h)  =  l2 


and  it  is  injective  (or  1-1  or  monic )  if 


VZ.Z'eLi  :/(0  =  /(Z')  =>/  =  !' 


The  function  /  is  monotone  (or  isotone  or  order-preserving)  if 


VZ,Z'  eLi  :lCi  l'  =►  /(Z)C2/(Z') 


It  is  an  additive  function  (or  a  join  morphism,  sometimes  called  a  distributive 
function)  if 

VZ1,Z2€£1:/(Z1UZ2)  =  /(Z1)U/(Z2) 
and  it  is  called  a  multiplicative  function  (or  a  meet  morphism)  if 


vz1,z2ei1:/(z1nz2)  =  /(z1)n/(z2) 

The  function  /  is  a  completely  additive  function  (or  a  complete  join  mor¬ 
phism)  if  for  all  Y  C  Lp 

/( U^)  =  L]  2  {f(l')  |  Z'  €  Y}  whenever  [_J  1 Y  exists 
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and  it  is  completely  multiplicative  (or  a  complete  meet  morphism )  if  for  all 
YCLv 

/(TV)  =  FI 2{/(0  1 1'  £  Y)  whenever  f]i Y  exists 

Clearly  Llx  Y  and  [~|iT  always  exist  when  L\  is  a  complete  lattice;  when 
is  not  a  complete  lattice  the  above  statements  also  require  the  appropriate 
least  upper  bounds  and  greatest  lower  bounds  to  exist  in  Z-2-  The  function 
/  is  affine  if  for  all  non-empty  Y  C  L\ 

/(U>y)=U  2  {/(/')  |  /'  G  Y}  whenever  [J  i  Y  exists  (and  Y  ^  0) 

and  it  is  strict  if  /(±i)  =  ±2i  note  that  a  function  is  completely  additive  if 
and  only  if  it  is  both  affine  and  strict. 

Lemma  A. 4  If  L  =  (L,  C,u,n,  1,  T)  and  M  =  (M,C,U,n,±,T)  are 
complete  lattices  and  M  is  finite  then  the  three  conditions 

(i)  7  :  M  -t  L  is  monotone, 

(ii)  7(T)  =  T,  and 

(iii)  7 (mi  n  m2)  =  7(mi)  n  7(012)  whenever  mi  £  m2  A  m2  £  mi 

are  jointly  equivalent  to  7  :  M  -»  L  being  completely  multiplicative.  ■ 

Proof  First  note  that  if  7  is  completely  multiplicative  then  (i),  (ii)  and  (iii)  hold. 
For  the  converse  note  that  by  monotonicity  of  7  we  have  7(minmj)  =  7(mi)ri7(m2) 
also  when  mi  C  m2  V  m2  C  mi.  We  then  prove  by  induction  on  the  (finite) 
cardinality  of  M'  C  M  that: 

7(|>')  =flWm)  I  m  €  M'}  (A.2) 

If  the  cardinality  of  M'  is  0  then  (A.2)  follows  from  (ii).  If  the  cardinality  of  M'  is 
larger  than  0  then  we  write  M'  =  M"  U  {m"}  where  m"  £  M"\  this  ensures  that 
the  cardinality  of  M"  is  strictly  less  than  that  of  M'\  hence: 

7(0')  =  7((0")nm") 

=  7(0")  n7(-") 

=  ((  |  {tC771)  I  m  €  M"})  n  7 (m") 

=  (~|{7(m)  I  m  €  M'} 

This  proves  the  result.  ■ 

Lemma  A. 5  A  function  /  :  ( V(D),C )  — »  (V{E),  C)  is  affine  if  and  only 
if  there  exists  a  function  ip  :  D  — >•  V{E)  and  an  element  <p§  €  V[E)  such  that 

f(Y)  =  {jMd)\deY}uw 

The  function  /  is  completely  additive  if  and  only  if  additionally  ipq,  =  0.  ■ 
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Proof  Suppose  that  /  is  of  the  form  displayed  and  let  y  be  a  non-empty  set;  Then 

(J{/(y)  \vey)  =  (J{(jM<f)  \deY}u<p,  \y  ey} 

=  U{U^d)idey>iy€y>U¥>0 

=  (JM<0  |d€  (Jy}  Uipt 

=  n\Jy) 

showing  that  /  is  affine. 

Next  suppose  that  /  is  affine  and  define  (p(d)  =  f({d})  and  =  /(0).  For 
Y  €  V{D)  let  y  =  {{d}  |  d  €  Y)  U  {0}  and  note  that  Y  =  (J  y  and  y  #  0.  Then 

f(Y)  =  f({Jy) 

=  U^d»idey>u^0») 

=  U(Md))ldsy}u{w}) 

=  (JM<*)  |  d  e  F}  U  (fit 

so  /  can  be  written  in  the  required  form.  The  additional  statement  about  com¬ 
pletely  additivity  is  straightforward.  ■ 

An  isomorphism  from  a  partially  ordered  set  ( L\ ,  Ci)  to  a  partially  ordered 
set  (1/2,  C2)  is  a  monotone  function  0  :  L\  -»  L2  such  that  there  exists  a 
(necessarily  unique)  monotone  function  6~l  :  L2  ->  Li  with  6  o  9~1  =  id2 
and  o  9  =  idi  (where  idi  is  the  identity  function  over  Li,  i  =  1,2). 


A.2  Construction  of  Complete  Lattices 

Complete  lattices  can  be  combined  to  construct  new  complete  lattices.  We 
shall  first  see  how  to  construct  products  and  then  two  kinds  of  function  spaces. 

Cartesian  product.  Let  Li  =  (Li,  Ei)  and  L2  =  {L2,  C2)  be  partially 
ordered  sets.  Define  L  =  ( L ,  C)  by 

L  =  {(h,h)  |  h  €  L\  A  l2  E  L2} 


and 

(huhi)  E  (^12,^22)  iff  Ei  J12  A  l2i  C2  I22 

It  is  then  straightforward  to  verify  that  L  is  a  partially  ordered  set.  If  ad¬ 
ditionally  each  Li  =  (Li,  C;,  -Li,  T*)  is  a  complete  lattice  then  so  is 

L  =  (L,  C,  U.n.-L,  T)  and  furthermore 

LJy  =  <  U  1O1  |  312  :  (h,h)  E  Y }  ,  [_\2{l2  I  3 h  :  (h,l2)  €  Y}  ) 
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and  ±  =  (±i,±2)  and  similarly  for  f"]Y  and  T.  We  often  write  L\  x  L2  for 
L  and  call  it  the  cartesian  product  of  L\  and  L2. 

A  variant  of  the  cartesian  product  called  the  smash  product  is  obtained  if  we 
require  that  all  the  pairs  (h,l2)  of  the  lattice  satisfy  li  =  ±1  &  l2  =  -L2. 

Total  function  space.  Let  L\  =  (Li,Cx)  be  a  partially  ordered  set 
and  let  5  be  a  set.  Define  L  =  ( L ,  C)  by 

L  =  {/  :  S  -4  Li  |  /  is  a  total  function} 


and 

/  C  /'  iff  Vs  6  5  :  f(s)  /'(s) 

It  is  then  straightforward  to  verify  that  L  is  a  partially  ordered  set.  If 
additionally  Li  =  (ii,  Ci, U1»(—ii»  -Li, Ti)  is  a  complete  lattice  then  so  is 
L  =  (L,  C,  U,  li  >  -L>  T)  and  furthermore 

(Jr  =  As.[J1{/(s)  |/er> 

and  _L  =  As.i-i  and  similarly  for  [~~|  Y  and  T.  We  often  write  S  ->  L\  for  L 
and  call  it  the  total  function  space  from  S  to  L\ . 

Monotone  function  space.  Again  let  Li  =  (Li,Ci)  and  L2  = 
(L2iQ2)  be  partially  ordered  sets.  Now  define  L  =  ( L ,  C)  by 

L  =  {/  :  L\  ->  L2\  f  is  a  monotone  function} 

and 

/  E  /'  iff  V/x  G  Lt  :  f(h)  C2  f%) 

It  is  then  straightforward  to  verify  that  L  is  a  partially  ordered  set.  If  ad¬ 
ditionally  each  Li  =  (Lj,  JLj,  Tj)  is  a  complete  lattice  then  so  is 

L  =  (L,  C,  LJ, ["I  i  -L,  T)  and  furthermore 

[Jy  =  a/lLMM)  \f£Y) 

and  ±  =  AIi. ±2  and  similarly  for  flY  and  T.  We  often  write  L\  — >  L2  for  L 
and  call  it  the  monotone  function  space  from  Li  to  L2. 


A. 3  Chains 

The  ordering  C  on  a  complete  lattice  L  =  (L,  C)  expresses  when  one  prop¬ 
erty  is  better  (or  more  precise)  than  another  property.  When  performing  a 
program  analysis  we  will  typically  construct  a  sequence  of  elements  in  L  and 
it  is  the  general  properties  of  such  sequences  that  we  shall  study  now.  In  the 
next  section  we  will  be  more  explicit  and  consider  the  sequences  obtained 
during  a  fixed  point  computation. 
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Chains.  A  subset  Y  C  L  of  a  partially  ordered  set  L  =  (L,  C)  is  a  chain 
if 

Vli,l2eY:(hQl2)V(hCh) 

Thus  a  chain  is  a  (possibly  empty)  subset  of  L  that  is  totally  ordered.  We 
shall  say  that  it  is  a  finite  chain  if  it  is  a  finite  subset  of  L. 

A  sequence  (ln)n  =  (ln)ne N  of  elements  in  L  is  an  ascending  chain  if 

n  <  m  =*•  ln  C  lm 

Writing  ( ln)n  also  for  {ln  |  n  G  N}  it  is  clear  that  an  ascending  chain  also  is 
a  chain.  Similarly,  a  sequence  (/„)„  is  a  descending  chain  if 

n  ^  771  — ^  In  D  Ifji 

and  clearly  a  descending  chain  is  also  a  chain. 

We  shall  say  that  a  sequence  (Z„)„  eventually  stabilises  if  and  only  if 

3no  G  N  :  Vn  G  N  :  n  >  no  =>  ln  =  lno 

For  the  sequence  (/„)„  we  write  |Jn  Jn  for  |  n  G  N}  and  similarly  we 
write  riJn  for  \~\{lTi  |  n  G  N}. 

Ascending  Chain  and  Descending  Chain  Conditions.  We 

shall  say  that  a  partially  ordered  ,set  L  =  (L,  C)  has  finite  height  if  and  only 
if  all  chains  are  finite.  It  has  finite  height  at  most  h  if  all  chains  contain  at 
most  h  +  1  elements;  it  has  finite  height  h  if  additionally  there  is  a  chain  with 
h  +  1  elements.  The  partially  ordered  set  L  satisfies  the  Ascending  Chain 
Condition  if  and  only  if  all  ascending  chains  eventually  stabilise.  Similarly,  it 
satisfies  the  Descending  Chain  Condition  if  and  only  if  all  descending  chains 
eventually  stabilise.  These  concepts  are  related  as  follows: 

Lemma  A. 6  A  partially  ordered  set  L  =  ( L ,  C)  has  finite  height  if  and 
only  if  it  satisfies  both  the  Ascending  and  Descending  Chain  Conditions.  ■ 

Proof  First  assume  that  L  has  finite  height.  If  (ln)n  is  an  ascending  chain  then  it 
must  be  a  finite  chain  and  hence  eventually  stabilise;  thus  L  satisfies  the  Ascending 
Chain  Condition.  In  a  similar  way  it  is  shown  that  L  satisfies  the  Descending  Chain 
Condition. 

Next  assume  that  L  satisfies  the  Ascending  Chain  Condition  as  well  as  the  Descend¬ 
ing  Chain  Condition  and  consider  a  chain  Y  CL.  We  shall  prove  that  Y  is  a  finite 
chain.  This  is  obvious  if  Y  is  empty  so  assume  that  it  is  not.  Then  also  (Y,  C)  is 
a  non-empty  partially  ordered  set  satisfying  the  Ascending  and  Descending  Chain 
Conditions. 

As  an  auxiliary  result  we  shall  now  show  that 

each  non-empty  subset  Y'  of  Y  contains  a  least  element  (A-3) 
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Figure  A.2:  Two  partially  ordered  sets. 


To  see  this  we  shall  construct  a  descending  chain  ( l'n)n  in  Y'  as  follows:  first  let  1'0 

be  an  arbitrary  element  of  Y' .  For  the  inductive  step  let  l'n+i  =  l'n  if  l'n  is  the  least 

element  of  Y'\  otherwise  we  can  find  l'n+1  €  Y'  such  that  l'n+l  C  l'n  A  l'n+1  l'n. 

Clearly  ( l'n)n  is  a  descending  chain  in  Y ;  since  Y  satisfies  the  Descending  Chain 

Condition  the  chain  will  eventually  stabilise,  i.e.  3 n'o  :  Vn  >  n'0  :  l'n  =  l',  and  the 

71 0 

construction  is  such  that  l',  is  the  least  element  of  Y' . 

"o 

Returning  to  the  main  proof  obligation  we  shall  now  construct  an  ascending  chain 
(Zn)„  in  Y.  Using  (A. 3)  each  Z„  is  chosen  as  the  least  element  of  the  set  Y  \ 
{Zo,  •  •  ■  ,in-i}  as  long  as  the  latter  set  is  non-empty,  and  this  yields  Zn- 1  C  Z„  A 
ln-i  /  Z„;  when  Y  \  {Zo,  •  •  • ,  Zn-i}  is  empty  we  set  ln  —  In- 1,  and  since  Y  is  non¬ 
empty  we  know  that  n  >  0.  Thus  we  have  am  ascending  chain  in  Y  and  using  the 
Ascending  Chain  Condition  we  have  3no  :  Vn  >  no  :  ln  —  ln0  ■  But  this  means  that 
Y  \  {Zo,  •  •  • ,  ln0 }  =  0  since  this  is  the  only  way  we  can  achieve  that  Z„0+i  =  Z„0 .  It 
follows  that  Y  is  finite.  ■ 

Example  A. 7  The  partially  ordered  set  of  Figure  A.2  (a)  satisfies  the 
Ascending  Chain  Condition  but  does  not  have  finite  height;  the  partially 
ordered  set  of  Figure  A.2  (b)  satisfies  the  Descending  Chain  Condition  but 
does  not  have  finite  height.  ■ 

One  can  show  that  each  of  the  three  conditions  finite  height,  ascending  chain, 
and  descending  chain,  is  preserved  under  the  construction  of  cartesian  prod¬ 
uct:  if  L\  and  L?  satisfies  one  of  the  conditions  then  L\  x  Z,2  will  also  satisfy 
that  condition.  The  construction  of  total  function  spaces  S  L  only  pre¬ 
serves  the  conditions  of  L  if  5  is  finite  and  the  construction  of  monotone 
function  spaces  L\  — >  L2  does  not  in  general  preserve  the  conditions. 

An  alternative  characterisation  of  complete  lattices  satisfying  the  Ascending 
Chain  Condition  is  given  by  the  following  result: 
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Lemma  A. 8  For  a  partially  ordered  set  L  =  ( L ,  Q  the  conditions 

(i)  L  is  a  complete  lattice  satisfying  the  Ascending  Chain  Condition,  and 

(ii)  L  has  a  least  element,  .L,  and  binary  least  upper  bounds  and  satisfies 
the  Ascending  Chain  Condition 

are  equivalent.  ■ 

Proof  It  is  immediate  that  (i)  implies  (ii)  so  let  us  prove  that  (ii)  implies  (i).  Using 
Lemma  A. 6  it  suffices  to  prove  that  all  subsets  Y  of  L  have  a  least  upper  bound 
|J  Y.  If  Y  is  empty  clearly  |J  Y  =  ±.  If  Y  is  finite  and  non-empty  then  we  can 
write  Y  =  {j/i ,  -  •  •  ,yn}  for  n  >  1  and  it  follows  that  [JK  =  (•  •  •  (j/i  Uy2)  U-  •  •)  Lly„. 

If  Y  is  infinite  then  we  construct  a  sequence  (!„)„  of  elements  of  L:  let  lo  be  an 
arbitrary  element  y0  of  Y  and  given  ln  take  ln+\  =  l„  in  the  case  where  Vy  6  Y  :yC 
ln  and  take  ln+ 1  =  ln  U  yn+i  in  the  case  where  some  y„+ 1  €  Y  satisfies  yn+i  2  In- 
Clearly  this  sequence  is  an  ascending  chain.  Since  L  satisfies  the  Ascending  Chain 
Condition  it  follows  that  the  chain  eventually  stabilises,  i.e.  there  exists  n  such  that 
ln  =  ln+i  =  •••.  This  means  that  Vy  €  Y  :  y  C  ln  because  if  y  2  in  then  ln  ^  lnUy 
and  we  have  a  contradiction.  So  we  have  constructed  an  upper  bound  for  Y.  Since 
it  is  actually  the  least  upper  bound  of  the  subset  {yo,  •  •  ■ ,  yn}  of  Y  it  follows  that 
it  is  also  the  least  upper  bound  of  Y.  a 

A  related  result  is  the  following: 

Lemma  A. 9  For  a  complete  lattice  L  =  (L,C)  satisfying  the  Ascending 
Chain  Condition  and  a  total  function  /  :  L  -»  L,  the  conditions 

(i)  /  us  additive,  i.e.  \/li,h  •  f{h  U  h)  =  f(h)  U  f{h),  and 

(ii)  /  is  affine,  i.e.  \/Y  C  L,  Y  ?  0  :  /((J  Y)  =  (J{/(0  1 1  €  Y} 

are  equivalent  and  in  both  cases  /  is  a  monotone  function.  ■ 

Proof  It  is  immediate  that  (ii)  implies  (i):  take  Y  =  {fi ,  I2}-  It  is  also  immediate 
that  (i)  implies  that  /  is  monotone  since  h  C  I2  is  equivalent  to  ii  U  h  =  h- 

Next  suppose  that  /  satisfies  (i)  and  let  us  prove  (ii).  If  Y  is  finite  we  can  write 
Y  =  (yi,  •  •  •  ,y„}  for  n  >  1  and 

/( U  Y)  =  /fa  U  •  •  •  U  yn)  =  /(yi)  U  •  •  •  U  /(y„)  C  I  1  *  Y) 

If  Y  is  infinite  then  the  construction  of  the  proof  of  Lemma  A.8  gives  [J  Y  =  Z„ 
and  =  y„  U  ■  ■  •  U  yo  for  some  yi  £  Y  and  0  <  i  <  n.  We  then  have 

/( U  Y)  =  /(M  =  f(v»  LJ  •  •  •  u  yo)  =  f(yn)  U  •  •  •  U  /(y0)  C  |J{/(0  1 1  €  Y) 

Furthermore 

f{\jY)3\_j{f(l)\leY} 

follows  from  the  monotonicity  of  /.  This  completes  the  proof.  ■ 
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A. 4  Fixed  Points 

Reductive  and  extensive  functions.  Consider  a  monotone  func¬ 
tion  /  :  L  -*  L  on  a  complete  lattice  L  =  (L,  C,  |_J, [“1  >  -L>  T).  A  fixed  point  of 
/  is  an  element  l  £  L  such  that  f(l)  =  l  and  we  write 

Fix(f)  =  {z  i  m = i} 

for  the  set  of  fixed  points.  The  function  /  is  reductive  at  l  if  and  only  if 
/(/)  C  l  and  we  write 

Red(f)  =  {l 1  HI)  E  0 

for  the  set  of  elements  upon  which  /  is  reductive;  we  shall  say  that  /  itself 
is  reductive  if  Red(f)  =  L.  Similarly,  the  function  /  is  extensive  at  l  if  and 
only  if  f(l)  □  l  and  we  write 

Ext(f)  =  {l\f(l)2l} 

for  the  set  of  elements  upon  which  /  is  extensive;  we  shall  say  that  /  itself  is 
extensive  if  Ext(f)  =  L. 

Since  L  is  a  complete  lattice  it  is  always  the  case  that  the  set  Fix{f)  will 
have  a  greatest  lower  bound  in  L  and  we  denote  it  by  Ifp(/): 

lfp(f)  =\~\Fix(f) 

Similarly,  the  set  Fix(f)  will  have  a  least  upper  bound  in  L  and  we  denote  it 
by  gfp(ffi 

gfp(f)  —  |_J  Fix(f) 

We  then  have  the  following  result,  known  as  Tarski’s  Fixed  Point  Theorem, 
showing  that  lfp(f)  is  the  least  fixed  point  of  /  and  that  gfp(f)  is  the  greatest 
fixed  point  of  /: 


Proposition  A.  10 

Let  L  =  ( L ,  Ei  U.lli-l,  T)  be  a  complete  lattice.  If  /  :  L  — >  L  is 
a  monotone  function  then  lfp{f)  and  gfp(f)  satisfy: 

lfp(f)  =  n  Red(f)  £  Fix(f) 
gfp(f)  =  \JExt(f)  E  Fix(f) 


Proof  To  prove  the  claim  for  lfp(f)  we  define  lo  =  [~| Red(f).  We  shall  first  show 
that  f(lo)  C  lo  so  that  lo  E  Red(f).  Since  lo  E  2  for  all  l  E  Red(f)  and  /  is 
monotone  we  have 


/(Jo)  E  f(l)  C  l  for  all  l  E  Red(f) 
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T 

/n(T) 

rin/n(T) 

gfp(f) 

Wf) 

U  n/”(-J-) 

/"(- 1) 


Figure  A.3:  Fixed  points  of  /. 


and  hence  f(lo)  C  lo.  To  prove  that  lo  C  f(l0 )  we  observe  that  f(f(lo))  E  f{lo) 
showing  that  f(lo)  €  Red(f)  and  hence  lo  C  /(lo)  by  definition  of  lo.  Together  this 
shows  that  lo  is  a  fixed  point  of  /  so  Zo  €  Fix(f).  To  see  that  lo  is  least  in  Fix(f) 
simply  note  that  Fix(f)  C  Red(f).  It  follows  that  =  lo- 

The  claim  for  gfp(f)  is  proved  in  a  similar  way.  ■ 

In  denotational  semantics  it  is  customary  to  iterate  to  the  least  fixed  point  by 
taking  the  least  upper  bound  of  the  sequence  (fn(±))„.  However,  we  have  not 
imposed  any  continuity  requirements  on  /  (e.g.  that  =  L_ln(/(M) 

for  all  ascending  chains  ( ln)n )  and  consequently  we  cannot  be  sure  to  actually 
reach  the  fixed  point.  In  a  similar  way  one  could  consider  the  greatest  lower 
bound  of  the  sequence  (/n(T))n.  One  can  show  that 

-L  E  n-L)  E  e  W) 

E  gfp(f)  E  n-TfO  E  /n(T)  E  t 

as  is  illustrated  in  Figure  A.3;  indeed  all  inequalities  (i.e.  C)  can  be  strict 
(i.e.  C).  However,  if  L  satisfies  the  Ascending  Chain  Condition  then  there 
exists  n  such  that  /n(±)  =  /”+1(±)  and  hence  lfp(f)  =  /n(-L).  (Indeed  any 
monotone  function  /  over  a  partially  ordered  set  satisfying  the  Ascending 
Chain  Condition  is  also  continuous.)  Similarly,  if  L  satisfies  the  Descending 
Chain  Condition  then  there  exists  n  such  that  /n(T)  =  /n+1(T)  and  hence 
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gfp(f)  =  /"( T). 

Remark  ( for  readers  familiar  with  ordinal  numbers).  It  is  possible  always 
to  obtain  lfp(f)  as  the  limit  of  an  ascending  (transfinite)  sequence  but  one 
may  have  to  iterate  through  the  ordinals.  To  this  effect  define  ft*  G  L  for 
an  ordinal  k  by  the  equation 

f'K  = 

and  note  that  for  a  natural  number  n  we  have  =  /n+1  (_L).  Then  lfp(f)  = 
ft*  whenever  k  is  a  cardinal  number  strictly  greater  than  the  cardinality  of 
L,  e.g.  k  may  be  taken  to  be  the  cardinality  of  V(L).  A  similar  construction 
allows  to  obtain  gfp(f)  as  the  limit  of  a  descending  (transfinite)  chain.  ■ 


Concluding  Remarks 

For  more  information  on  partially  ordered  sets  consult  a  text  book  (e.g.  [33]). 


Appendix  B 

Induction  and  Coinduction 


We  begin  by  reviewing  a  number  of  techniques  for  conducting  inductive 
proofs.  We  then  motivate  the  concept  of  coinduction  and  finally  formulate 
a  general  proof  principle  for  coinduction.  This  makes  heavy  use  of  Tarski’s 
Fixed  Point  Theorem  (Proposition  A.10). 


B.l  Proof  by  Induction 

Mathematical  induction.  Perhaps  the  best  known  induction  princi¬ 
ple  is  that  of  mathematical  induction.  To  prove  that  a  property,  Q(n),  holds 
for  all  natural  numbers,  n,  we  establish 

Q(  o) 

Vn  :  Q(n )  =>  Q(n  +  1) 


and  conclude 

Vn  :  Q(n) 

Formally,  the  correctness  of  mathematical  induction  can  be  related  to  the  fact 
that  each  natural  number  is  either  0  or  the  successor,  n  -I- 1,  of  some  other 
natural  number,  n.  Thus  the  proof  principle  reflects  the  way  the  natural 
numbers  are  constructed. 

Structural  induction.  Mathematical  induction  allows  us  to  perform 
induction  on  the  size  of  any  structure  for  which  a  notion  of  size  can  be  defined; 
this  is  just  a  mapping  from  the  structure  into  the  natural  numbers.  As  an 
example  consider  an  algebraic  data  type  given  by 

de  D 

d  ::=  Base  |  Con^d)  |  Con2(d,  d) 
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where  Base  is  a  base  case,  Coni  is  a  unary  constructor  and  Con2  is  a  binary 
constructor.  To  prove  that  a  certain  property,  Q(d),  holds  for  all  elements, 
d,  of  D  we  can  define  a  size  measure: 

size(Base)  =  0 
size(  Coni  (d))  =  1  +  size(d) 

size(Con2(di,  d2))  =  1  +  size(di)  +  size(d2) 

and  then  proceed  by  mathematical  induction  on  size(d)  to  prove  Q(d). 

Alternatively  we  can  conceal  the  mathematical  induction  within  a  principle 
of  structural  induction:  we  must  then  show 

<5(Base) 

Vd  :  Q(d)  =$>  Q(Coni(d)) 

Vdi,d2  :  Q(di)  A  Q(d2)  =$>  Q(Con2(di,d2)) 

from  which  we  conclude 

Vd :  Q(d) 

Once  again  the  proof  principles  reflects  the  way  the  data  are  constructed. 

Induction  on  the  shape.  Now  suppose  that  Base  represents  0,  that 
Coni(d)  represents  d  +  1,  and  that  Con2(di,d2)  represents  di  +  d2.  We  can 
then  define  a  Natural  Semantics  - 


d  n 


for  evaluating  d  into  the  number,  n,  it  represents: 


[base]  Base  -»  0 


[coni] 


[con2] 


d->  n 

Coni(d)  -»•  n  +  1 

di  — ^  ni  d2  — ^  n2 
Con2(di,d2)  ->ni  +n2 


This  defines  a  notion  of  evaluation  trees,  d  %  n:  there  is  one  base  case 
([ftase])  and  two  constructors  ([coni]  and  [con2]).  Again  we  can  perform 
induction  on  the  size  of  the  evaluation  trees  but  as  above  it  is  helpful  to 
conceal  the  mathematical  induction  within  a  principle  of  induction  on  the 
shape  of  inference  trees:  we  must  show 

<2(Base  0) 


d—^n 


V(d  %  n)  :  Q(d  %  n)  ^  Q 


Con -h  1 
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V(di  fii),  (^2  ^2)  ;  QiAi  Tii)  A  Q(d2  n 2)  =.■ 

q  (  di  ni  d2  — ^  7^2 

l  Con2(di,d2)  -»  ni  +  Ti2 

from  which  we  conclude 

V(d  ^  n)  :  Q(d  3  n) 

As  is  to  be  expected,  the  proof  principle  once  again  reflects  the  way  evaluation 
trees  are  constructed. 

Course  of  values  induction.  All  of  the  above  induction  principles 
have  been  constructive  in  the  sense  that  we  establish  a  predicate  for  the  base 
cases  and  then  show  that  it  is  maintained  by  all  constructors.  A  variant  of 
mathematical  induction  with  a  different  flavour  requires  proving 

Vn  :  (Vm  <  n  :  Q{m))  =$■  Q(n) 

from  which  we  conclude 

Vn  :  Q(n) 

Here  the  base  case  is  dealt  with  in  the  same  manner  as  the  induction  step. 
This  induction  principle  is  called  course  of  values  induction. 

Well-founded  induction.  Course  of  values  induction  is  an  instance 
of  a  very  powerful  induction  principle  called  well-founded  induction.  Given  a 
partially  ordered  set  ( D ,  ^),  the  partial  ordering  is  a  well-founded  ordering 
if  there  is  no  infinite  decreasing  sequence 

di  >-  d2  >-  d3  y  •  ■  • 

where  d  y  d'  means  d'  <d  A  d  ^  d'  -  this  amounts  to  the  Descending  Chain 
Condition  studied  in  Appendix  A.  The  principle  of  well-founded  induction 
then  says:  if  we  show 

Vd  :  (W  -<  d  :  Q{d'))  =>  Q(d) 

we  may  then  conclude 

Vd :  Q(d) 

(The  proof  of  correctness  of  this  principle  is  along  the  lines  of  the  proof  of 
(A.3)  in  Lemma  A.6  and  can  be  found  also  in  the  literature  referenced  below.) 


B.2  Introducing  Coinduction 

To  explain  the  difference  between  induction  and  coinduction,  and  to  motivate 
the  need  for  coinductive  methods,  let  us  consider  a  small  example.  Consider 
the  program 
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if  j(27,m)  then  “something  good”  else  “something  bad” 

where  /  is  a  function  from  pairs  of  natural  numbers  (i.e.  pairs  of  non-negative 
integers)  to  truth  values. 

We  want  to  ensure  that  the  program  never  undertakes  to  do  “something 
bad”.  Since  the  value  of  m  is  not  known  it  is  not  feasible  to  prove  that 
/(27,  m)  7^  false  by  merely  evaluating  /(27,m);  we  therefore  need  to  perform 
some  kind  of  proof.  For  this  it  is  natural  to  define  the  predicate  Q/  as  follows 

Q/(n)  iff  Vm  :  /(n,m)  ^  false 

where  it  is  implicit  that  m,n>  0. 

Perhaps  the  most  obvious  approach  is  to  use  mathematical  induction  to  prove 
Vn  :  Q/(n).  This  amounts  to  proving 

Q/(0) 

Vn  :  Q/(n)  =$■  Q/(n  +  1) 


and  then  concluding 

Vn :  Qf  (n) 

from  which  the  desired  Q/(27)  follows. 

An  alternative  presentation  of  essentially  the  same  idea  is  to  establish  the 
validity  of  the  axiom  and  rule 


Q/(0) 


Q/(») 

Q/(n  +  1) 


and  then  deduce  that 

Vn  :  Q/(n) 

Here  the  basic  steps  in  the  mathematical  induction  have  been  couched  in 
terms  of  an  inductive  definition  of  the  predicate  Qf. 

The  approach  outlined  above  works  nicely  for  the  function  /o  defined  by 


/o(0,m)  =  true 

/o(n  +  l,m)  =  /o(n,m) 


but  what  about  the  functions  fi ,  /2  and  /3  defined  by 


/i(0,m)  =  /i(0,m) 

/i(n  +  l,m)  =  /i(n,m) 


/2(0,m) 
/2(n  +  l,m) 


=  true 
=  /2(n  +  l,m) 


/3(0,m)  =  /3(0,m) 

/3(n  +  l,m)  =  /3(n  +  l,m) 
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where  /j(27,m)  never  terminates?  Intuitively,  they  should  be  acceptable  in 
the  sense  that  “something  bad”  never  happens.  However,  we  cannot  prove 
this  by  induction  because  we  cannot  establish  the  base  case  (for  fi  and  /3) 
and/or  we  cannot  establish  the  inductive  step  (for  / 2  and  /a). 

An  intuitive  argument  for  why  fi  is  acceptable  might  go  as  follows:  assume 
that  all  occurrences  of  fi  on  the  right  hand  sides  of  the  above  definitions 
satisfy  Q i]  then  it  follows  that  also  the  /<  on  the  left  hand  side  does.  Hence 
fi  satisfies  Qi,  i.e.  Vn  :  Qi(n).  This  sounds  very  dangerous:  we  assume  the 
desired  result  in  order  to  prove  it.  However,  with  due  care  and  given  the 
proper  definition  of  Qi,  this  is  a  valid  proof:  it  is  a  coinductive  proof. 

Obtaining  a  functional.  Let  us  rewrite  the  defining  clauses  of  fi  into 
clauses  for  Qi  so  as  to  clarify  the  relationship  between  when  Qi  holds  on  the 
left  hand  side  and  on  the  right  hand  side  of  the  definitions  of  fit 


Qo(0)  iff 

true 

Qi(0)  iff 

Qi(0) 

Qo(n  +  l)  iff 

Qo(n) 

Qi(n  +  1)  iff 

Qi(n) 

(B.l) 

Q2(0)  iff 

true 

Q3(0)  iff 

Qs(0) 

Q2(n  +  1)  iff 

Q2(n  +  1) 

Q3(n  +  1)  iff 

Q3(n  + 1) 

Here  the  clauses  for  Q0 

looks  just  like 

our  principle  for  mathematical  indue- 

tion  whereas  the  others  involve  some  amount  of  circularity.  To  make  this 

evident  let  us  rewrite  the  above  as 

Qi  = 

Qi(Qi) 

(B.2) 

where 

Qo(Q'XO)  = 

true 

Qi(Q'XO) 

=  <2'(0) 

Qo(Q')(n  +  l)  = 

Q'(n) 

Qi(Q')(n  +  1) 

=  Q'(n) 

(B.3) 

Q2(Q')(  0)  = 

true 

Qs(Q')(0) 

=  Q’(  0) 

Q2(Q')(n  + 1)  = 

Q'(n  + 1) 

Q3(Q')(n  +  1) 

=  Q'(n  + 

1) 

Clearly  Qi  satisfies  (B.l)  if  and  only  if  it  satisfies  (B.2)  with  Q,  as  in  (B.3). 
It  is  immediate  that  each  Qi  is  a  monotone  function  on  the  complete  lattice 

(N  — >  {true,  false} ,  C) 

of  predicates  where  Q 1  C  Qi  means  that  Vn  :  Qi(n)  =>■  Q2(n)  and  where  the 
least  element  X  is  given  by  Vn  :  X(n)  =  false  and  the  greatest  element  T  is 
given  by  Vn  :  T  (n)  =  true.  Using  Tarski’s  Fixed  Point  Theorem  (Proposition 
A.  10)  it  follows  that  each  Qi  has  a  least  fixed  point  lfp(Qi)  and  a  greatest 
fixed  fixed  point  gfp(Qi)',  these  are  possibly  different  predicates  in  (N  — > 
{true,  false},  C). 
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Least  fixed  point.  Let  us  begin  by  looking  at  the  least  fixed  points. 
It  follows  from  Appendix  A  that 

[_]  fcQo(-*-)  E  ifp(Qo) 

and  given  that  the  clauses  for  Qo(Q)  only  use  a  finite  number  of  Q’s  on  the 
right  hand  sides  (in  fact  zero  or  one),  Qo  satisfies  a  continuity  property  that 
ensures  that 

|_|*Q*(.L)=i$>(Q0) 

This  is  good  news  because  our  previous  proof  by  mathematical  induction 
essentially  defines  the  predicate  (J*  Qo(-L):  2o(-*-)(n)  holds  if  and  only  if  at 
most  k  axioms  and  rules  suffice  for  proving  Qo(n).  Thus  it  would  seem  that 
a  proof  by  induction  “corresponds”  to  taking  the  least  fixed  point  of  Qo. 

Next  let  us  look  at  Q3.  Here 


Ifp(Qs)  =  1 

because  Q3(±)  =  1  so  that  ±  is  a  fixed  point.  This  explains  why  we  have 
lfp(Q3) (27)  =  false  and  why  an  inductive  proof  will  not  work  for  establishing 
Qs(27).  Somewhat  similar  arguments  can  be  given  for  Qi  and  Q2. 

Greatest  fixed  point.  Let.  us  next  look  at  the  greatest  fixed  points. 
Here 

gfp(Qs)  =  T 

because  Q3(T)  =  T  so  that  T  is  a  fixed  point.  This  explains  why  we  have 
gfp(Q.3)(27)  =  true  and  thus  provides  a  formal  underpinning  for  our  belief 
that  /3  will  not  cause  any  harm  in  the  example  program.  Somewhat  similar 
arguments  can  be  given  for  Qi  and  Q2. 

Also  for  Qo  it  will  be  the  case  that  gfp(Q0)(27)  =  true.  This  is  of  course 
not  surprising  since  lfp(Qo)(27)  =  true  and  lfp(Qo)  E  gfp(Qo)-  However, 
it  is  more  interesting  to  note  that  for  Qo  there  is  no  difference  between  the 
inductive  and  the  coinductive  approach  (unlike  what  is  the  case  for  Qi ,  Q2 
and  Q3): 

Ifp(Qo)  =  gfp(Qo) 

because  mathematical  induction  on  n  suffices  for  proving  that  lfp{Qo)(n )  = 
gfp(Qo)(n). 

Remark.  To  the  mathematically  inclined  reader  we  should  point  out  that 
the  fact  that  lfp(Q0)  =  gfp(Qo)  is  related  to  Banach’s  Fixed  Point  Theorem: 
a  contractive  operator  on  a  metric  space  has  a  unique  fixed  point.  Contrac¬ 
tiveness  of  Qo  (as  opposed  to  Qi,  Q2  and  Q3)  follows  because  the  clause  for 
Qo(Q)(n)  only  performs  calls  to  Q  on  arguments  smaller  than  n.  ■ 
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Consider  once  again  the  algebraic  data  type 
dSD 

d  ::=  Base  |  Coni(d)  |  Con2(d,  d) 

with  one  base  case,  one  unary  constructor  and  one  binary  constructor.  Next 
consider  the  definition  of  a  predicate 


Q  :  D  -4  {true,  false} 


by  means  of  clauses  of  the  form 

Q(Base) 

iff  • 

.. 

Q(Coni(d)) 

iff  • 

•  •  Q(d')  ■  •  • 

Q(Con2(di,d2)) 

iff  • 

■■Q(d[)---Q(d'2) 

We  can  use  this  as  the  basis  for  defining  a  function  Q  by  cases  as  in 

Q(Q')(Base)  =  ••• 

Q(Q')(Coni(d))  =  •••<?'(<*')••• 

Q(Q')(  Conafa,*))  =  ■■■Q'(d[)---Q'(d,2)--- 

We  note  that 

(D  ->  {true,  false},  C) 

is  a  complete  lattice  under  the  ordering  given  by  Q i  C  Q2  if  and  only  if 
Vd  :  Qi(d)  =>  Q2(d).  We  also 

assume  that  Q  is  monotone 

and  this  means  that  e.g.  a  clause  like  “Q(Corii(d))  iff  ~>Q(d)”  will  not  be 
acceptable.  From  Proposition  A.  10  it  follows  that  Q  has  a  least  as  well  as  a 
greatest  fixed  point. 

Induction  (or  least  fixed  point).  Consider  first  the  inductive  def¬ 
inition 


Q  =  lfp(Q)  (B.4) 


This  is  more  commonly  written  as 


Q(Base) 


■  Q(d') 


Q(Coni(d)) 


■■■Q(d[)---Q(d'2)--- 

Q(Con2(di,d2)) 


(B.5) 


It  is  often  the  case  that  each  rule  only  has  a  finite  number  of  calls  to  Q 
and  then  the  two  definitions  are  equivalent:  the  predicate  in  (B.5)  amounts 
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to  |_|jfe  Qfc(-L)  and  by  a  continuity  property  as  discussed  above,  this  agrees 
with  the  predicate  of  (B.4).  A  proof  by  induction  then  simply  amounts  to 
establishing  the  validity  of  the  axioms  and  rules  in  (B.5).  Such  a  proof  has  a 
very  constructive  flavour:  we  take  nothing  for  granted  and  only  believe  what 
can  be  demonstrated  to  hold.  This  proof  strategy  is  often  used  to  reason 
about  semantics  because  the  semantics  of  a  program  should  not  allow  any 
spurious  behaviour  that  is  not  forced  by  the  semantics. 

Coinduction  (or  greatest  fixed  point).  Consider  next  the  coin - 
ductive  definition 


Q  =  gfp(Q) 

A  proof  by  coinduction  then  amounts  to  using  the  proof  rule 

Q'  E  om  (■  p  Q'QQ(Q')\ 

Q'QQ  V  Q'  Q  gfp(Q)J 

as  follows  from  the  formula  for  gfp(Q)  given  in  Proposition  A. 10.  So  to  prove 
Q(d)  one  needs  to 


find  some  Q'  such  that 
Q'(d) 

W  uQ'(d')  =»  Q(Q')(d') 

Such  a  proof  has  a  very  optimistic  flavour:  we  can  assume  everything  we  like 
as  long  as  it  cannot  be  demonstrated  that  we  have  violated  any  facts.  It  is 
commonly  used  for  checking  that  a  specification  holds  because  the  specifica¬ 
tion  should  not  forbid  some  behaviour  unless  explicitly  called  for. 

It  sometimes  saves  a  bit  of  work  to  use  the  derived  proof  rule 

Q'  C  Q{Q  U  Q') 

Q't  Q 

To  see  that  this  is  a  valid  proof  rule  suppose  that  Q'  C  Q(Q  U  Q').  By 
definition  of  Q  we  also  have  Q  C  Q(Q)  and  by  monotonicity  of  Q  this  gives 
Q  C  Q( Q  U  Q').  Hence 

QUQ'  C  Q(Q  U  Q') 

and  Q  U  Q'  C  Q  follows  by  definition  of  Q.  It  is  then  immediate  that  Q'  C  Q 
as  required. 

Clearly  this  explanation  can  be  generalised  to  algebraic  data  types  with  ad¬ 
ditional  base  cases  and  constructors,  and  from  predicates  to  relations. 
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Example  B .  1  Consider  the  relations 

Ri  :  Du  x  Du  -*•  {true, false) 

R2  :  Du  x  Du  ->  {true,  false} 

defined  by 

Ri  =  7li(Ri,  R2) 

R2  =  7£2(Rl,  R2) 

This  is  intended  to  define 

(Ri,R2)=«fr(ft) 

where  TZ(R[,Ri)  =  (1li(Ri,  R^))  is  assumed  to  be  monotone. 

Next  write  R'  U  R"  for  the  relation  defined  by 

di  (R1  U  R")  d2  iff  (di  R'  da)  V  (d,  R"  d2) 
and  write  R'  C  R"  for  the  truth  value  defined  by 

R'  C  R"  iff  Wud2  :  di  R!  d2  =>  dx  R"  d2 
We  then  have  the  following  version  of  the  coinduction  principle:  we  establish 

R'i  E  Ki{R[,R!i) 

R!a  E  RiiR'uR^) 

and  conclude 

R[  C  Ri  and  R^  C  R2 

In  analogy  with  before,  it  sometimes  saves  a  bit  of  work  only  to  show 

R[  C  77-1  (Ri  U  R[,  R2  U  R^) 

R'2  E  772(Ri  U  R{,  R2  LI  R^) 

because  we  also  have 

Ri  E  72-i(Ri,  R2)  C  7^i (Ri  LI  iij ,  R2  U  i?2) 

R2  E  712(Ri,  R2)  C  7^2(Ri  LI  R'i ,  R2  U  R^) 

and  this  allows  us  to  conclude 


R{  C  Ri  and  R^  O  R2 


using  the  definition  of  (Ri,  R2)  =  gfp(TZ). 


Concluding  Remarks 

For  more  information  on  induction  principles  consult  a  text  book  (e.g.  [10]). 
It  is  harder  to  find  good  introductory  material  on  coinduction;  one  possibility 
is  to  study  the  work  on  strong  bisimulation  in  CCS  (e.g.  Chapter  4  of  [80]). 


Appendix  C 

Graphs  and  Regular 
Expressions 


(This  material  remains  to  be  integrated.) 
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Data,  179 
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Offset,  327 
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SType,  300 
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RD entry,  42 

RDexijj  42 
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Mi  281 
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AExp(-),  36 
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MFP,  72 
MOP,  77 
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substitution,  295 
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